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

Use Long Options in Scripts

matklad.github.io

Post reply on HN
Print view View original

71–80 of 157 posts

Re: Use Long Options in Scripts

#71

Post by gray_-_wolf »

delusional wrote: post #60
gray_-_wolf wrote: post #47

Earlier quoted context omitted.

Another approach is to have powerful enough language that allows you to guard against the shell injection. I wrote a syntax form allowing to do this: (sh "cat " file " >" output) With file being bound to "foo'bar" and output to "x", it is automatically translated into cat 'foo'\''bar' >'x' This gives you the flexibility to use shell (sometimes it just is the most concise way) while being safe against injection. I bel…

How do you know which shell you're escaping for? You could query the system, but now you end up implementing escaping for every shell out there.

Good question. I care only about POSIX compatible shells, so the escaping just follows the POSIX rules. In practice that means it works on any actually used system except windows, which is fine with me.

Re: Use Long Options in Scripts

#72

Post by skydhash »

olejorgenb wrote: post #50
userbinator wrote: post #26

Earlier quoted context omitted.

Because not everyone has 20 or more years of flag memory from using Linux It's called learning , apparently something that is now being eschewed in favour of quick superficiality (and making developers more replaceable --- with AI or unskilled offshore labour.) No wonder "modern" software is almost always total shit. "But I don't have the time to learn," you complain, but ask yourself this instead: Why do you never h…

Learning that this tool can be used do these things, manipulate these objects or stream of data like this, and that this tool is useful in combination with these other tools are the valuable part. Memorizing some arbitrary encoding of the parameters are not really useful when I can offload it to my language center in the brain and basically get that part for free...

Why do you conflate learning with memorizing? man is easy to do. And you take notes, write script, functions and alias for things you do often.

Re: Use Long Options in Scripts

#73

Post by [deleted] »

pcwalton wrote: post #10
saagarjha wrote: post #9

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.

What POSIX systems in actual use (not historical Unixes) don't have the long options? macOS' BSD utilities I guess?

[deleted]

Re: Use Long Options in Scripts

#74

Post by SoftTalker »

yjftsjthsd-h wrote: post #27
pcwalton wrote: post #10

Earlier quoted context omitted.

What POSIX systems in actual use (not historical Unixes) don't have the long options? macOS' BSD utilities I guess?

> What POSIX systems in actual use (not historical Unixes) don't have the long options? All of them except for GNU, AFAICT? (That is, only GNU seems to have long options.) Checking manpages for rm(1) as a simple reference, I can't see long options in any of the 3 major BSDs or illumos, and checking Alpine Linux seems to show busybox also only doing short options (sorry, can't find an online doc for this, though it's…

More than this, the gnu utilities often have options that don't exist at all on other platforms, in either long or short form.

Re: Use Long Options in Scripts

#76

Post by crazygringo »

wahern wrote: post #6

Please DO NOT mix string interpolation and command execution, especially when a command is processed through the shell. Whatever your language, use a list-based or array-based execution API that passes arguments straight through to execv(2), execvp(2), etc, bypassing the shell.

For anything involving file paths, user input, etc. -- yes of course. It's not even a question because they would need to be escaped otherwise which nobody wants to do.

But for a simple example like this where it's inserting a date which has known properties, it seems fine, and is much more readable.

Re: Use Long Options in Scripts

#77

Post by JimDabell »

userbinator wrote: post #26
mplanchard wrote: post #17

Earlier quoted context omitted.

Because not everyone has 20 or more years of flag memory from using Linux, and they’ve also got to maintain the scripts. If you’re not familiar with every arcane invocation of find or tar or whatever, or even if it’s just been a while, the long options are a godsend when you’re skimming a script trying to figure out what it’s doing.

Because not everyone has 20 or more years of flag memory from using Linux It's called learning , apparently something that is now being eschewed in favour of quick superficiality (and making developers more replaceable --- with AI or unskilled offshore labour.) No wonder "modern" software is almost always total shit. "But I don't have the time to learn," you complain, but ask yourself this instead: Why do you never h…

I’ve got almost 30 years of using UNIX shells and I’ve learnt a lot more than most, but there are plenty of tools that have things like -r and -R that do radically different things and I don’t always remember the difference between them. If it’s written --recursive then it’s a lot clearer. Clarity is useful even when you have a lot of knowledge and experience.

Re: Use Long Options in Scripts

#78

Post by cedilla »

userbinator wrote: post #25
01HNNWZ0MV43FF wrote: post #21

Earlier quoted context omitted.

Programs are read more often than they're written, and on a scale of decades all programmers are novices. So I try to optimize my code to be obvious to novices What's wrong with GNU? they automatically wrong or something?

So I try to optimize my code to be obvious to novices That's the attitude which is responsible for making software the way it is today: mediocre.

Software is mediocre today? You should have seen it back in the day. It was a brittle, arcane mess.

Software isn't as exciting any more, but that excitement isn't gone because newbs don't have to look up what -O stands for anymore. It's because it's wildly more reliable.

Re: Use Long Options in Scripts

#79

Post by sgarland »

delusional wrote: post #62
saghm wrote: post #34

Earlier quoted context omitted.

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…

I think the right way to think about this (if your goal is to avoid surprises at least) is that options (short or long) are just strings. There's no guarantee that there's a long variant of an option. There's not even a requirement that options start with a dash. A sufficiently brain-damaged developer could start them with a slash or something. If you're going for portability the best bet is to just read the manual f…

To this day, I write tar options with no dash, simply because I can. `tar cvzf foo.tar.gz ./foo`

I would never write a new program with this option, but I do find it a delightful historical oddity.

Re: Use Long Options in Scripts

#80

Post by rat87 »

remus wrote: post #68
rat87 wrote: post #39

Earlier quoted context omitted.

Only if you are getting input from untrusted users

imo it's best to just avoid it altogether. Requirements change, and what was once a trusted input can become untrusted input.

Generally you shouldn't be passing random data from the web to shell scripts. Maybe I haven't done the right type of work but having to deal with fidlg bits it's much more likely not passing it to be shell will cause issues (with stuff like executable paths)
Post reply on HN