61–70 of 157 posts
Earlier quoted context omitted.
Yes. The famous echo on Linux systems does not have it and therefore it's impossible to print the string "-n o p e", because -n will be interpreted as an option.
echo is not portable anyway, use "printf %s STRING" or "printf '%s\n' STRING".
Agree that long options should be used. But there is one caveat to consider: portability. Sadly to this day not all BSD distributions have GNU style long options. And the ones that now do only got them fairly recently. So if you want portability you have to use short options as you weep with a bottle of vodka in hand.
This surprises me because the first case I remember ever coming across where short versus long options impacted portability across GNU and BSD was _fixed_ by using long options. Maybe six years ago or so I had an issue porting a script someone else had written for use in CI that happened to decode some base64 data that failed when I tried to use it on a different platform. I forget which one it was originally written…
If you're going for portability the best bet is to just read the manual for each of the separate versions and do whatever works.
Unfortunately, if you want your scripts to be portable to other POSIX systems you might have to use the short options, as the long ones are not standardized. You have to decide the tradeoff for yourself.
Using nix has really spoiled me on this. Everyone gets the same versions of all the CLI utilities in the dev environment, whether on mac or linux, and those are the same versions that run in CI and any prod systems. It’s really nice being able to use whichever newer bash features or gawk extensions you like, without having to deal with trying to ensuring the mac engineers have brew-installed all the right stuff to ma…
It's exactly the same thing people initially loved about docker or vagrant.
Strongly, strongly disagree. This is a GNU-ism, and needlessly verbose. What's with people refusing to use the vast amount of memory in their brains and actually learning, instead lazily going for the lowest-common-denominator approach relying on "loanwords" from English?
Earlier quoted context omitted.
[flagged]
[flagged]
Talk to any electrician which kinds of diagrams they prefer; those were a fellow was clever, trying to compress stuff as much as possible, or those that are clearly readable and easy to understand. Pilots carry heaps of documentation with them on the plane, walk through checklists instead of trying to memorise what to do. Your argument doesn’t hold up the slightest scrutiny.
I’m advocating for a culture of helping people hone their skills by learning from others instead of being turned off by their arrogance. That’s a very different thing from encouraging them to avoid thinking.
Earlier quoted context omitted.
Yes of course. But why would you expect me to run shell commands with random person's input? Also: safe_exec(["rm", user_input]) This isn't safe either! Despite clearly saying "safe_exec"!
Yeah, "safe_exec" is a useless name without context. But the context was you need to call a program from another program. Many people would call system() or whatever because usually it's obvious and easy, and the pitfalls are less so. Shelling out is not the only option. People are just saying not to use that option. Better ones won't save you if you purposely do something stupid. They will save you if the user wants…
Earlier quoted context omitted.
But not all shell utilities follow this particular convention
Yes. The famous echo on Linux systems does not have it and therefore it's impossible to print the string "-n o p e", because -n will be interpreted as an option.
what if I or someone wrote a bot / script that searches across github for every shell script file that it can find and converts all short options into long options and opens a PR? Think dependabot but lets call it longabot or readabot?