131–140 of 157 posts
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.
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…
FreeBSD doesn’t come with bash though.
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…
Earlier quoted context omitted.
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.
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…
> 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…
I think MacOS still has bash, so that it, technically, doesn’t count, but it doesn’t have a bash from the past decade, and uses zsh by default.
Earlier quoted context omitted.
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?
(Running an older version of macOS so can't completely exclude this has been updated in a newer version, but I'd be surprised to learn that was true.)
Earlier quoted context omitted.
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…
sh is smarter than just doing string interpolation and ”$1” is passed on as a single argument, no matter what:
> run(["sh", "-c", 'echo "$1"', "--", 'a"'])
a”
> run(["sh", "-c", 'echo "a""')
--: 1: Syntax error: Unterminated quoted string
Earlier quoted context omitted.
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…
I don’t really follow. My “good” example and the code at the bottom are the same. sh is smarter than just doing string interpolation and ”$1” is passed on as a single argument, no matter what: > run(["sh", "-c", 'echo "$1"', "--", 'a"']) a” Whereas if it were simple string interpolation, you’d see this: > run(["sh", "-c", 'echo "a""') --: 1: Syntax error: Unterminated quoted string It’s the same special casing that g…
# cat pvars.sh
#!/bin/bash
echo "\$1=$1"
echo "\$2=$2"
echo "\$3=$3"
# sh -c './pvars.sh "$1" $2 $3' -- 'a b' 'c d'
$1=a b
$2=c
$3=d
foo "bar baz" quux
If you have an array of params and you're jumping through hoops to make sure they're interpreted correctly by the shell you call execute a process, you're likely (depending on language and capabilities) wasting both cycles and over complicating the code when you can just call the program you actually want to execute directly and supply the params. Alternatively, if you have all the params as one long string and you want it to be pased as a shell would, then execute the shell and pass that as a param. e.g.
# perl -E 'system("./pvars.sh","a b","c d");'
$1=a b
$2=c d
$3=
# perl -E 'system("./pvars.sh","a b","c","d");'
$1=a b
$2=c
$3=dEarlier 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…
FreeBSD doesn’t come with bash though.
But being honest - you can install BASH that way:
# pkg install -y bash
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.
The gobsmackingly ancient GNU software it does have is bash, because it's the last version under GPL 2. I've used Mac OS X since 10.1, so I remember when the default shell was tcsh and /bin/sh was not bash.
That's (basically) the case again on the last few macOS releases. Today, zsh is my shell of choice, including on Linux.