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

41–50 of 157 posts

Re: Use Long Options in Scripts

#41

Post by pletnes »

less_less wrote: post #38
arcanemachiner wrote: post #35

Earlier quoted context omitted.

I know to do this intuitively, but I have no idea why.

It tells the shell utility that any remaining arguments are not options, but instead files or whatever the script might process. You know, in case someone makes a file called -rf.

But not all shell utilities follow this particular convention

Re: Use Long Options in Scripts

#42

Post by bulatb »

tasuki wrote: post #30
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.

Why not?

Any time you send commands and data down a single channel, user input that's intended to be data can be misinterpreted as a command. For example, if your program wants to:

    run("program --option '{user_input}' > file")
to save some input to a file, and the user's input is:

    '; bad_command #
then when run() sends that string to the shell, the shell will run:

    program --option '';
    bad_command #' > file
Most languages have something like a safe_exec() that separates the shape of the command from the values of the options, executing "program" with the options and the user_input in the arguments array as data. Skipping the shell step, which would just be building an exec call anyway, removes the opportunity for users to confuse it into doing something else.

The list-based API alternative they recommend might look like this:

    safe_exec(["program", "--option", user_input], stdout="file")
and it would always exec "program" with argv[1] == "--option" && argv[2] == user_input. If the user_input happens to be:

    '; bad_command #
...well, then, the user can enjoy the contents of their file.

Re: Use Long Options in Scripts

#43

Post by userbinator »

9dev wrote: post #36
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…

[flagged]

[flagged]

Re: Use Long Options in Scripts

#44

Post by ribcage »

pletnes wrote: post #41
less_less wrote: post #38

Earlier quoted context omitted.

It tells the shell utility that any remaining arguments are not options, but instead files or whatever the script might process. You know, in case someone makes a file called -rf.

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.

Re: Use Long Options in Scripts

#45

Post by userbinator »

biorach wrote: post #31
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…

You're confusing learning with memorization.

It's the lowest, easiest level of learning.

Re: Use Long Options in Scripts

#46

Post by tasuki »

bulatb wrote: post #42
tasuki wrote: post #30

Earlier quoted context omitted.

Why not?

Any time you send commands and data down a single channel, user input that's intended to be data can be misinterpreted as a command. For example, if your program wants to: run("program --option '{user_input}' > file") to save some input to a file, and the user's input is: '; bad_command # then when run() sends that string to the shell, the shell will run: program --option ''; bad_command #' > file Most languages have…

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"!

Re: Use Long Options in Scripts

#47

Post by gray_-_wolf »

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.

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 believe for example in rust you should be able to do the same.

Re: Use Long Options in Scripts

#48

Post by sebastianmestre »

dosourcenotcode wrote: post #15
croes wrote: post #13

> Long form options are much more self-explanatory for the reader. And less prone to typos

And not just options but base command names too. I wrote a tool to partially mitigate this in some cases: https://github.com/makesourcenotcode/name-safe-in-bash

You have a nice ternary counter going in the version numbers :)

Re: Use Long Options in Scripts

#49

Post by hackerthemonkey »

pletnes wrote: post #41
less_less wrote: post #38

Earlier quoted context omitted.

It tells the shell utility that any remaining arguments are not options, but instead files or whatever the script might process. You know, in case someone makes a file called -rf.

But not all shell utilities follow this particular convention

Yes. It’s more of a convention. If a shell utility isn’t following it then it won’t mean what we think it would mean.

Also - it helps a lot when a utility accepts a path that may or may not contain hyphens.

Re: Use Long Options in Scripts

#50

Post by olejorgenb »

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…

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...
Post reply on HN