@lazurski
Also, because many commands are used from interactive shell way more often than are written in scripts, people remember the short options very well, but don't necessarily know what the corrsepointing long options are.
So they type what they remember.

Considering that shell scripts are write-only anyway, that shouldn't be an issue.

@Wolf480pl

I can somewhat agree about interactive use and the way they creep into scripts. But what about scripts shipped with packages? They often constitute important part of the OS.

Also I don't think they are write-only. Today I got triggered because I was trying to debug particularly nasty and weird behavior of DNSMasq and found out that there is a systemd unit file calling a script that is calling few other scripts and most of them use options like -5 or -7. I was very much reading it 😠

@Wolf480pl In the end it boils down to taking some care and effort to make the code accessible to other people. I think to enable software freedoms we should be taking this effort.

@lazurski
well, I'd say that there's a few things that went wrong here:

- dnsmasq having stupid option names. Using numbers as option names should be done very rarely and with great care. -6 is --dhcp-script ? I'd expect it to be --ipv6-only...

- someone packaging shell scripts instead of execlineb scripts. bourne/korn/bourne-again shell isn't too good for writing simple wrappers around other executables.

- someone treating a packaged shell script like a script instead of a program

@lazurski
So yeah, if someone is packaging a shell script, they should probably treat it as if it was a program written in any other programming language, and make sure it's readable and maintainable.

And while they're at it, consider rewriting it in a more maintainable language, if it's bigger than 100 lines.

I think writing anything bigger than 100 lines of code in shell is wrong. Eg. Arch's netctl, however well it works, should've been written in a normal programming language.

@lazurski also note that there are no long options in POSIX, so if you're using a program like ls or cp, and want your script to be portable, you shouldn't use the implementation-specific long options.

@Wolf480pl I know. It's lamentable. Still, if possible, I would always prefer long options.

Actually, when peer programming I use long options even in interactive sessions to encourage my peers to use them. With modern shells we often get auto-completion for options, so it's not very cumbersome, and we save time on explaining which option does what.

@Wolf480pl True. The shell scripting orgy that was SysV init is one of the reasons I am really happy about Systemd adoption in Linux. Sure it has it's own issues, but generally it's so much easier to understand what's going on in the system.

Now I probably acquired some haters

💣 💣 💣

@Wolf480pl Did you see that:

https://chaos.social/@lazurski/100165918771401406

What do you use for automation?

@lazurski If it's below 100 lines of code, I use shell.
Can't remember needing a piece of automation bigger than 100 LoC, but I'd probably use python up to 1k LoC. Above that, I'd look for something statically typed.

Also, my shell scripts tend to be small, and use other shell scripts with descriptive names.

@Dog2puppy well, there are exceptions. I actually thought about iteration counters when choosing my words. Hence "generally". Another, and perhaps better, example would be "x", "y" and "z" when refering to coordinates in euclidean system.

@Dog2puppy But these are exceptions.