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

121–130 of 157 posts

Re: Use Long Options in Scripts

#121

Post by pwdisswordfishz »

gorgoiler wrote: post #90
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.

Miniature, in-line sh scripts are also fine as long as you use the provided parameter substitution. If you’re averse to this: q(“select x where y = ‘“ + v + “‘“) And instead do this: q(“select x where y = %s”, v) Then you should be averse to this: x(“foo --option ‘“ + v + “‘“) And instead do this: x(‘foo --option “$1”’, v) This is particularly useful when it’s expedient to have one thing piping into another. Like it…

    SyntaxError: invalid character '“' (U+201C)

Re: Use Long Options in Scripts

#122

Post by theamk »

susam wrote: post #84

I prefer long options too. However, while writing programs that need to invoke POSIX commands in a portable manner, short options are the only viable choice, as POSIX doesn't specify long options. For instance, see the specification for diff at https://pubs.opengroup.org/onlinepubs/9799919799/utilities/d... >, or that of any POSIX utility listed at https://pubs.opengroup.org/onlinepubs/9799919799/idx/utiliti... >. Th…

Note that grep in particular is extremely optimized.. If you have multi-gigabyte files, and you only search for one thing, shelling out to grep will likely have much better performance that doing it yourself.

But not every system needs that much, and in a lot of cases, using your language's regexp library will be more robust anf easier to write.

Re: Use Long Options in Scripts

#123

Post by lapsed_lisper »

I used to think this, but now mostly (but weakly) don't. Long options buy expressiveness at the cost of density, i.e., they tend to turn "one-liners" into "N-liners". One-liners can be cryptic, but N-liners reduce how much program fits on the screen at once. I personally find it easier to look up flags than to have to page through multiple screenfuls to make sense of something. In this respect, ISTM short options are a /different/ way of helping a subsequent reader, by increasing the odds they see the forest, not just the trees.

Re: Use Long Options in Scripts

#124

Post by OJFord »

Timon3 wrote: post #117
Arrowmaster wrote: post #115

Earlier quoted context omitted.

From the output in the post I'm going to assume it's either a joke post or an LLM hallucination.

Oh god, it even says right there: > Warning: this utility is fake. Well played! I guess I got too excited at the possibility of such a tool existing.

Such a tool does exist, it's called shellcheck. If you give /bin/sh shebang for example it will tell you off using non-POSIX features regardless of whether they'll work with the sh on your system.

(Personally I typically use bash though, largely so I can `set -eEuo pipefail` next.)

Re: Use Long Options in Scripts

#125

Post by delusional »

mplanchard wrote: post #97
delusional wrote: post #63

Earlier quoted context omitted.

nix didn't solve your issue here. nix didn't do anything. You're just describing the benefit of a reproducible development environment. You could do the same thing with brew, pacman, apt, or by just compiling every package from source from some huge mirror. It's exactly the same thing people initially loved about docker or vagrant.

Sure, but it works on Mac and Linux and doesn’t require virtualization. I think brew might qualify, but it can’t define which environment variables should be available in the developer shell or which hooks to run upon entry. I don’t think any of the other options you specified can manage the same thing.

>[...] it can’t define which environment variables should be available in the developer shell or which hooks to run upon entry.

Neither pacman, apt, nor any other package manger require any sort of virtualization. pacman works fine where-ever you have a C compiler including macos, linux, windows, probably even TempleOS. Whatever you want.

If you want to add something to the user environment system wide, the traditional thing to do is to dump a file into `/etc/profile.d/` which will be sourced during shell startup. If you instead want something local to the project, you just make a script that the developer can source, like a python virtualenvironment.

I'm not saying any of these ideas are bad. I am saying that they are easily solvable and have been solved for the past 20 years. Without Nix.

Re: Use Long Options in Scripts

#127

Post by timewizard »

xyzzy9563 wrote: post #83
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.

You can always copy+paste it into an LLM and have it explain the options in 5 seconds.

I just use the man page. Which happily describes all the options in an easily digestible format that does not require either an ineternet connection or massive amounts of power to be wasted on a result that is almost certainly copyrighted and flat out stolen from it's original creator.

I am of a generation where I see these uses of LLMs as exceptionally lazy or showy. Your ready use of a "chatbot" is not an attribute to broadcast like this.

Re: Use Long Options in Scripts

#129

Post by samatman »

mceachen wrote: post #118
Wowfunhappy wrote: post #87

Earlier quoted context omitted.

> However, while writing programs that need to invoke POSIX commands in a portable manner ...probably a stupid question, but something I have earnestly been wondering about... when does this actually happen nowadays? What POSIX systems are you targeting that aren't one of the major ones (Linux, Darwin, or one of the major BSDs)? I was writing a shell script a few months ago that I wanted to be very durable, and I tar…

Alpine docker images only come with dash instead of bash, which _may_ run your sh script, but test thoroughly. Or just install bash. FWIW, Darwin/macOS is especially guilty of gobsmackingly ancient coreutils that don’t support long option variants.

Is it? I'm with you on gobsmackingly ancient, but it's "doesn't support long options" which I haven't bumped into. I do replace some coreutils, but not all of them.

What's a good example of such a utility?

Re: Use Long Options in Scripts

#130

Post by kbenson »

gorgoiler wrote: post #90
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.

Miniature, in-line sh scripts are also fine as long as you use the provided parameter substitution. If you’re averse to this: q(“select x where y = ‘“ + v + “‘“) And instead do this: q(“select x where y = %s”, v) Then you should be averse to this: x(“foo --option ‘“ + v + “‘“) And instead do this: x(‘foo --option “$1”’, v) This is particularly useful when it’s expedient to have one thing piping into another. Like it…

Neither of those are equivalent to variable binding, which is what most SQL libraries provide, specifically because they don't actually solve the problem since they're still doing string substitution. Putting a double quotes in $1 in your "good" execute example will allow you break out of what's expected and then you're Bobby Tables.

Your python example at the bottom is correct, in that each separate element is more correct in that it allows each arg to be passed as an element, so there's no option to break out through quoting characters. SQL binds are like that in most ljbraries, even if they don't look like it. The parser knows a single item below there so if it passes it along as such. You cannot escape it in the same way.

Post reply on HN