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

51–60 of 157 posts

Re: Use Long Options in Scripts

#51

Post by hackerthemonkey »

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 is one thing and being able to comprehend a piece of code at a glance is another. I might know them but wouldn’t immediately remember all the past and future short form of flags ever written. What is even the point of that? If I am comfortable with the essence of what they do, does it really matter that much if I have that ingrained in my memory that -r does foo while -f does bar?

Re: Use Long Options in Scripts

#52

Post by hoherd »

arcanemachiner wrote: post #35
teddyh wrote: post #20

Also, do not forget using “--” after all options, but before any dynamic arguments, just to be safe.

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

It terminates argument parsing, so anything following it that starts with a hyphen will not be treated as an argument.

    $ echo 'hack the planet' > --help
    $ cat --help
    cat: illegal option -- -
    usage: cat [-belnstuv] [file ...]
    $ cat -- --help
    hack the planet
    $ rm -vf --help
    rm: illegal option -- -
    usage: rm [-f | -i] [-dIPRrvWx] file ...
           unlink [--] file
    $ rm -vf -- --help
    --help
    $ cat -- --help
    cat: --help: No such file or directory

Re: Use Long Options in Scripts

#53

Post by hackerthemonkey »

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.

Exactly that. Well said. I can control my learning but memory? Not as much.

Re: Use Long Options in Scripts

#55

Post by [deleted] »

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…

[deleted]

Re: Use Long Options in Scripts

#56

Post by bulatb »

tasuki wrote: post #46
bulatb wrote: post #42

Earlier quoted context omitted.

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

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 to trick you into doing something else.

Re: Use Long Options in Scripts

#57

Post by bonzini »

ribcage wrote: post #44
pletnes wrote: post #41

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.

echo is not portable anyway, use "printf %s STRING" or "printf '%s\n' STRING".

Re: Use Long Options in Scripts

#58

Post by ndsipa_pomu »

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

Most of the commonly used ones do, so it's easiest to just always do it and then remember the two or three utils that don't like it.

Re: Use Long Options in Scripts

#59

Post by [deleted] »

johnisgood wrote: post #37

What is this? Use libgit2 or use a proper language where you do not need exec(), do it in Bash, or do it in C with libgit2 or with popen() or something. Using "system()" in C is never the right thing to do, the least you can do is using popen(). Not sure in which language you use "try shell.exec", but I am not even sure that it is the right way.

[deleted]

Re: Use Long Options in Scripts

#60

Post by delusional »

gray_-_wolf wrote: post #47
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 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.
Post reply on HN