Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pure Sh Bible

github.com

Post reply on HN
Print view View original

111–120 of 138 posts

Re: Pure Sh Bible

#111

Post by throwawaaarrgh »

lozenge wrote: post #93
throwawaaarrgh wrote: post #87

Earlier quoted context omitted.

Oh, right, because it's not easy to cause errors in Python.

Python stops on errors. Bash may or may not. It depends on how your script was called. If your script is sourced you need to remember to set and restore the flags. In bash your data can accidentally become code. "rm $fn" usually deletes one file, but it might one day delete a few (spaces), or wildcard expansion makes it delete many. With Python, calling the function to delete one file will always delete one file. You…

oh come on, whatever is feeding files to the function I'll just trick into using some other data with different files. you don't need to "execute data" to have substitution bugs.

and it's easy to add status checks to your shell script just like you can for Python. exceptions are not the only way to stop on error. but it's sure a hell of a lot easier to have a non-working program in Python, whereas it's a lot easier for a shell script to keep working.

Re: Pure Sh Bible

#112

Post by Night_Thastus »

arendtio wrote: post #97

POSIX shell scripting is just broken. Don't get me wrong. I love doing it, but from a language design point it is abysmal. Just this week I tried to write a script to apply a custom function to a list of files. But the amount of time you spend just to make sure it works with special cases like spaces or new line characters in file names is not healthy. After all, it is probably one of the most standard scenarios. Fir…

Not only broken, but every single implementation of it is broken in different ways - even between those that claim to be POSIX-compliant.

Re: Pure Sh Bible

#113

Post by tpoacher »

teddyh wrote: post #57
tpoacher wrote: post #33

Regarding conditional expressions: I found something neat recently. The coreutils version of `test` doesn't have this, and when you use `test`, typically what you're using is the coreutils one. But if you use `builtin test` to force the bash builtin variant of `test`, this has a nice `-v` switch, which allows you to check if a variable is set. I found out about this recently when I had to use it in my bash argument p…

If you already assume bash, then you don’t need the “-v” option to the “test” builtin; just do if [ "${foo+some_string}" = "" ]; then echo "foo is unset" fi or, in your case: if test "${2+x}" = "" # i.e. if $2 is not set

True, but I consider this very hacky, error-prone, and unnecessary when a clear, bespoke test flag exists.

Also, if you prefer the "[ ... ]" syntax for testing, then you can use `-v` directly anyway (since that is equivalent to the builtin test keyword anyway).

Re: Pure Sh Bible

#114

Post by teddyh »

dmd wrote: post #105
teddyh wrote: post #59

Earlier quoted context omitted.

I hope I never have to be the one to read those scripts.

Why? They're generally much clearer and well-commented than what a rushed harried sysadmin would write.

But the lines and code snippets presumably won’t match the style of the rest of the program (or each other), so I guess that you’ll get programs which does things wildly differently from line to line.

Re: Pure Sh Bible

#115

Post by dmd »

teddyh wrote: post #114
dmd wrote: post #105

Earlier quoted context omitted.

Why? They're generally much clearer and well-commented than what a rushed harried sysadmin would write.

But the lines and code snippets presumably won’t match the style of the rest of the program (or each other), so I guess that you’ll get programs which does things wildly differently from line to line.

Sounds like you've never actually used it for writing code, and are basing this on how you think it works. As someone who uses it for hours a day every day for writing code ... no, it does not have that problem.

Re: Pure Sh Bible

#116

Post by arendtio »

JackSlateur wrote: post #107
arendtio wrote: post #97

POSIX shell scripting is just broken. Don't get me wrong. I love doing it, but from a language design point it is abysmal. Just this week I tried to write a script to apply a custom function to a list of files. But the amount of time you spend just to make sure it works with special cases like spaces or new line characters in file names is not healthy. After all, it is probably one of the most standard scenarios. Fir…

You can xargs a bash function That function must be exported before, for instance: my_function(){ ... } export -f my_function find | xargs my_function

Yeah, I know, but 'export -f' is not POSIX compliant [1]. In addition, I have read, that this solution has quite a bad performance [2].

1: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

2: https://stackoverflow.com/a/67780632/1149404

Re: Pure Sh Bible

#117

Post by TheAdamist »

cutler wrote: post #56

The Holy Grail of POSIX-portable shell scripts is irrelevant these days. Just use bash which is the default on most *nix systems.

Debian/ubuntu use dash for sh, instead of bash, which breaks a lot of scripts lazily assuming bash is sh.

Scripts that specify bash will work, assuming its installed though.

Re: Pure Sh Bible

#118

Post by awaythrow98765 »

wirthjason wrote: post #103
bee_rider wrote: post #61

Earlier quoted context omitted.

I enjoy using bash, and throw together little scripts now and then. It is convenient to be able to wrap up some bash commands and turn them into a script, when I realize I’ve been using them repeatedly. But, every time I see examples of how to write sh scripts properly, it makes me wonder if this is just the wrong way to look at the world. Maybe it would be easier to extend Python down to make it better for command l…

What would make Python better for command line use? Better alternatives to argparse in the standard library?

Easier, lightweight syntax for shell-like pipes, command execution and catching stdin/stdout/stderr.

Something like Perl's IPC::Run.

Also, more shell-relevant stuff in the default distribution, so that one doesn't need to care about any modules (which is the primary reason for using bash or even sh, those are installed practically everywhere along with at least coreutils and stuff). Edit: examples that a standard python doesn't really do would be quick and easy recursive directory traversal and doing stuff to files found there (like the unix 'find' tool), archive (de)compression, file attribute operations (not only simple permissions but also ACLs, xattrs, mknod, etc).

But the sister comment clarified it in another way, so this maybe irrelevant.

Re: Pure Sh Bible

#119

Post by awaythrow98765 »

cutler wrote: post #58
awaythrow98765 wrote: post #45

If you are at this level of required complexity as in those examples, you should use a proper programming language, not shell. Half those snippets fail with spaces in the wrong place, newlines, control characters, etc. I think all such shell "magic" should come with a huge disclaimer pointing the user at better alternatives such as perl or python. And all snippets should have the necessary caveats on horribly broken…

"perl or python". Don't forget Ruby.

Yes, but actually no: I was tempted to include it but didn't. The one big argument for bash and sh is ubiquity and compatibility. Perl also has those. Python is somewhat lacking in those. Ruby is very lacking on both.

Re: Pure Sh Bible

#120

Post by 1vuio0pswjnm7 »

lmz wrote: post #85
1vuio0pswjnm7 wrote: post #80

"A collection of pure POSIX sh alternatives to external processes." "Ternary Tests" Can anyone point to where in the POSIX standard ternary test are described. (NB. Pure POSIX sh is less featureful than Bash.) What am I missing. https://web.archive.org/web/20201219013931/https://pubs.open... Also these operators from C that the author includes. Is he suggesting these are available in POSIX sh. Quoting from the Pure S…

Those operators are in "2.6.4 Arithmetic Expansion" in your linked doc. See the link to "Arithmetic Precision and Operations"[1]. [1]: https://web.archive.org/web/20201219013931/https://pubs.open...

Thank you. This helps. But does that mean a POSIX shell, or any other UNIX utility, must implement these operators. Using them in shell scripts makes the scripts non-portable, e.g., Almquist sh, NetBSD Almquist sh or Debian Almquist sh do not support them. Maybe the author of the "Pure POSIX Sh Bible" always runs Bash in --posix mode. Hence "Pure POSIX sh".
Post reply on HN