Update scripts

[Humm42]

useful changes

[Humm42]

fixes FPS problems in streams

[wiltaylor]

Should say nixos not 9front :p

[Humm42]

Maybe he is using NixOS already, though.

[wiltaylor]

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

[ghost]

Just some thoughts.

[ghost]

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'.

[Humm42]

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.

[ghost]

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.

[ghost]

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.

[Humm42]

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.

[ghost]

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.

[Humm42]

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?

[ghost]

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 $i in
    \#\ mark)
        COMMANDS ;;
esac

[Humm42]

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

[ghost]

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

[Humm42]

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

[Humm42]

@terminalforlife I suggest you take the code my PR adds (from the shebang to the # mark), put it in a file and run it.