Live data from Hacker News

Use long flags when scripting (2013)

changelog.com

111–120 of 197 posts

Re: Use long flags when scripting (2013)

#111
post #13

Earlier quoted context omitted.

Unless you count things like Makefiles, I don't think I've ever written or encountered a "script" that was intended for use on multiple *nix flavors. This strikes me as a YAGNI situation: do it if it comes up, but not before.

This attitude is definitely something that makes my life harder. My OS is usually OpenBSD, and I constantly need to fix other people's scripts. It's not difficult to do, but it is annoying. I don't blame people for ignorance, but it'd be nice if people thought about portability. Non-portable scripts can also bite you on Linux, where Debian, for example, will swap out the shell from bash to dash for performance. but o…

It's really useful to have a *BSD user or two in your userbase complaining about your non-POSIX linuxisms, it improves the portability of your code no end ...

Re: Use long flags when scripting (2013)

#112
post #91

Earlier quoted context omitted.

Recent (as in, within the last ~3-5 years) versions of GNU tar automatically detect the type of compression and apply the appropriate tool, so you can often get away with `tar xvf`.

Actually close to 12 years, GNU tar 1.21 https://www.gnu.org/software/tar/ Another "recent" (much more recent IIRC) change is that you don't need the dot anymore in find to search in the current directory.

according to https://git.savannah.gnu.org/cgit/findutils.git/commit/find/..., this functionality has been present since findutils was moved under source control in 1996.

Re: Use long flags when scripting (2013)

#113

Earlier quoted context omitted.

I agree. To me, "sed -e" is an expression as a whole, and replacing -e with --expression is on the same level as aliasing "sed" to "stream-editor". Though I would make the list of "allowed" short flags very short. I can't think of many more than the ones you listed: mkdir -p sh -c cp -r tar -xaf tar -caf

Is -a a GNU extension? Doesn't seem to be in the man page for BSD tar.

it is, and it's unnecessary for decompression since GNU tar 1.21 according to a comment lower in the thread.

Re: Use long flags when scripting (2013)

#114

Earlier quoted context omitted.

tar is one of the worst. I think I know what those do without looking it up but I think most people look at that with bewilderment. Randall Munroe is always helpful in these matters and has this to say: https://xkcd.com/1168/

I remember 90% of the time which flag I want to use, but the other 10% sends me into a rage! =) I gave up and added this to my .bashrc: function extract() { if [ -f $1 ] ; then case $1 in *.tar.bz2) tar xvjf $1 ;; *.tar.gz) tar xvzf $1 ;; *.bz2) bunzip2 $1 ;; *.rar) unrar x $1 ;; *.gz) gunzip $1 ;; *.tar) tar xvf $1 ;; *.tbz2) tar xvjf $1 ;; *.tgz) tar xvzf $1 ;; *.zip) unzip $1 ;; *.Z) uncompress $1 ;; *.7z) 7z x $1…

  extract() {
    bsdtar -xf "$1"
  }
you can decompress things which are not files, such as stdin or device files. in addition, your code does not cover *.tar.xz (more common than tar.bz2 nowadays), or lzma, or lz4, or tar.zst, or many many other formats. further, it's not even consistent: bunzip2, gunzip, and unxz remove the input file, but tar, unrar, 7z, and zstd do not.

Re: Use long flags when scripting (2013)

#115
post #13

Earlier quoted context omitted.

Unless you count things like Makefiles, I don't think I've ever written or encountered a "script" that was intended for use on multiple *nix flavors. This strikes me as a YAGNI situation: do it if it comes up, but not before.

This attitude is definitely something that makes my life harder. My OS is usually OpenBSD, and I constantly need to fix other people's scripts. It's not difficult to do, but it is annoying. I don't blame people for ignorance, but it'd be nice if people thought about portability. Non-portable scripts can also bite you on Linux, where Debian, for example, will swap out the shell from bash to dash for performance. but o…

> Non-portable scripts can also bite you on Linux, where Debian, for example, will swap out the shell from bash to dash for performance. but others will not. So, even within the Linux ecosystem, you can end up with scripts that behave differently across distros.

From the bash man page, "If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well." Also you should not be including bashisms if your shebang is sh and not bash. So using bash as sh shouldn't generally be a problem, if you stick to the published Shell Command Language [0], unless you hit one of the cases where the spec is a bit ambiguous and shells implement it differently [1].

[0] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V... [1] https://stackoverflow.com/questions/16069339/different-pipel...

Re: Use long flags when scripting (2013)

#116
post #2

If you're trying to stick to the POSIX standard, you have to use short options for standard commands like grep, since the long options are GNU extensions.

Does anyone care about the standard? Let's be honest it's outdated, has a bad UX and is with the standards I would hold such a standard against today generally not so good. Sure systems seen try to somewhat be POSIX compliance but from my experience not because they care about POSIX but because that happen to overlap with the idea to be somewhat compiland with other similar systems so that porting software/scripts is…

Yeah I agree with this. I claimed a few years ago that you could view https://www.oilshell.org/ as a "better POSIX", and I still hold that view.

http://www.oilshell.org/blog/2018/01/28.html#limit-to-posix

Recent comment about this:

https://news.ycombinator.com/item?id=24428347

POSIX is just too limited and not what people use in practice.

If you want a portable shell script, in many cases my (biased) advice would be to make your script work on both bash and Oil. (Obviously there are short shell scripts which you may want to run on BSD, etc. This is more about big scripts, which POSIX falls down for.)

Oil already runs some of the biggest shell scripts in the world, many of them unmodified. Moreoever, when there's a patch necessary to run it, it often IMPROVES the program.

http://www.oilshell.org/blog/2020/06/release-0.8.pre6.html#p...

You'll be less tied to the vagaries of bash.

If anyone's script doesn't run under Oil, I'm interested. See https://github.com/oilshell/oil/wiki/What-Is-Expected-to-Run...

Re: Use long flags when scripting (2013)

#117

Earlier quoted context omitted.

tar is one of the worst. I think I know what those do without looking it up but I think most people look at that with bewilderment. Randall Munroe is always helpful in these matters and has this to say: https://xkcd.com/1168/

I remember 90% of the time which flag I want to use, but the other 10% sends me into a rage! =) I gave up and added this to my .bashrc: function extract() { if [ -f $1 ] ; then case $1 in *.tar.bz2) tar xvjf $1 ;; *.tar.gz) tar xvzf $1 ;; *.bz2) bunzip2 $1 ;; *.rar) unrar x $1 ;; *.gz) gunzip $1 ;; *.tar) tar xvf $1 ;; *.tbz2) tar xvjf $1 ;; *.tgz) tar xvzf $1 ;; *.zip) unzip $1 ;; *.Z) uncompress $1 ;; *.7z) 7z x $1…

I guess you only ever extract punctually named files. But it's still rather amusing that with the exception of 'case', the only places where $1 is properly quoted are the ones where it's not really necessary, and vice versa (but then again, it's not done for the parameter, but rather the single quotes).

Anyway, my advice to you and anyone else having trouble with tar is that "tar caf" and "tar xaf" are the only things most people need to remember about tar, with or without compression.

(In this case, most people means people who use tar, but so rarely that they have trouble remembering how to use it; they probably never use it for anything else other than (un)archiving. Also, xkcd isn't gospel.)

Re: Use long flags when scripting (2013)

#118

Earlier quoted context omitted.

Does anyone care about the standard? Let's be honest it's outdated, has a bad UX and is with the standards I would hold such a standard against today generally not so good. Sure systems seen try to somewhat be POSIX compliance but from my experience not because they care about POSIX but because that happen to overlap with the idea to be somewhat compiland with other similar systems so that porting software/scripts is…

Last published in 2018 (and actively being worked on) is not outdated. https://pubs.opengroup.org/onlinepubs/9699919799/ > Sure systems seen try to somewhat be POSIX compliance The mainstream systems you know and use adhere very rigorously to POSIX. GNU Libc, Kernel, Coreutils, ... and their counterparts in BSD Unixes, proprietary Unixes, Cygwin and whatnot all take POSIX seriously. POSIX is very helpful, and smart c…

Larry Wall said It's easier to port a shell than a shell script in 1998 ... 22 years later I still think that holds.

https://news.ycombinator.com/item?id=10104203

Although I would agree that there's a slight hole there: you still need to port stuff like coreutils and all the dependencies, which has been done of course. But I'd be happier if something like busybox was actually portable.

Re: Use long flags when scripting (2013)

#119

Earlier quoted context omitted.

tar is one of the worst. I think I know what those do without looking it up but I think most people look at that with bewilderment. Randall Munroe is always helpful in these matters and has this to say: https://xkcd.com/1168/

I remember 90% of the time which flag I want to use, but the other 10% sends me into a rage! =) I gave up and added this to my .bashrc: function extract() { if [ -f $1 ] ; then case $1 in *.tar.bz2) tar xvjf $1 ;; *.tar.gz) tar xvzf $1 ;; *.bz2) bunzip2 $1 ;; *.rar) unrar x $1 ;; *.gz) gunzip $1 ;; *.tar) tar xvf $1 ;; *.tbz2) tar xvjf $1 ;; *.tgz) tar xvzf $1 ;; *.zip) unzip $1 ;; *.Z) uncompress $1 ;; *.7z) 7z x $1…

You can use atool (https://www.nongnu.org/atool/) too. It is just some perl scripts wrapper around some commom extraction tools.
Post reply on HN