11–20 of 27 posts
Yes! Gstreamer v1.22 made the cut! So much great stuff. I was worried-- actually I though the freeze had already started... softer-freeze? https://gstreamer.freedesktop.org/releases/1.22/ https://news.ycombinator.com/item?id=34505574
Earlier quoted context omitted.
This is ridiculous, isn't it just a shell script? Why would they get rid of it? I don't get it.
There was discussion about it. https://news.ycombinator.com/item?id=29026623
> "surely no one competent would choose to have a package depend on `which` when a standard POSIX utility can do a better job".
This is one of the most ridiculous takes I've heard and severely out of touch with shell scripts out in the wild, to say nothing of the expectations of Unix users typing at an interactive shell.
First time I used Debian was '99 or 2000. It's been a go-to Linux distro for me for a long time. This is disappointing.
Earlier quoted context omitted.
This is ridiculous, isn't it just a shell script? Why would they get rid of it? I don't get it.
There was discussion about it. https://news.ycombinator.com/item?id=29026623
One interesting change: > The which program has been deprecated, and writes a warning to standard error (but still works, so long as stderr is not being captured along with stdout). Shell script writers are advised to use command -v instead. Interactive bash shell users are advised to use type, or type -a. In zsh which is already a shell builtin, so interactive zsh users are not affected.
What's the long form of "-v"? Shell scripts should use long form options for clarity. As it stands, `command -v` is inscrutable.
One interesting change: > The which program has been deprecated, and writes a warning to standard error (but still works, so long as stderr is not being captured along with stdout). Shell script writers are advised to use command -v instead. Interactive bash shell users are advised to use type, or type -a. In zsh which is already a shell builtin, so interactive zsh users are not affected.
If so, this is huge!
Earlier quoted context omitted.
There was discussion about it. https://news.ycombinator.com/item?id=29026623
Quoted by the lwn article: > "surely no one competent would choose to have a package depend on `which` when a standard POSIX utility can do a better job". This is one of the most ridiculous takes I've heard and severely out of touch with shell scripts out in the wild, to say nothing of the expectations of Unix users typing at an interactive shell. First time I used Debian was '99 or 2000. It's been a go-to Linux dist…
Earlier quoted context omitted.
Quoted by the lwn article: > "surely no one competent would choose to have a package depend on `which` when a standard POSIX utility can do a better job". This is one of the most ridiculous takes I've heard and severely out of touch with shell scripts out in the wild, to say nothing of the expectations of Unix users typing at an interactive shell. First time I used Debian was '99 or 2000. It's been a go-to Linux dist…
I stopped using which some time ago because while it worked fine to bootstrap Debian based distros I found out it wasn't included in arch. Since then I always default to command -v. I don't see the problem, it already wasn't portable and as can be seen in this thread including it gives the false impression that it was.
The only portability wrinkle I've personally seen is that old Solaris behaved differently when the program isn't found. It would say "no $1 in $PATH" to stdout, whereas more recent systems just don't display anything.
One interesting change: > The which program has been deprecated, and writes a warning to standard error (but still works, so long as stderr is not being captured along with stdout). Shell script writers are advised to use command -v instead. Interactive bash shell users are advised to use type, or type -a. In zsh which is already a shell builtin, so interactive zsh users are not affected.
I was taught, back in the late 20th century, to never use the “which” program in shell scripts, since that program has its own logic on what programs are available, and that might differ from the method the actual shell uses to find programs, and this could obviously lead to subtle bugs. I was taught to use “type” instead, since, IIRC, “command” did not exist at the time.
This reminds me of the suggestion not to use access(2) and X_OK to decide to call execve(2) -- because the kernel behavior of executing the binary may work differently and fail for some other reason, or perhaps even there's a race condition where the executable bit gets removed between your calls.
This is typical advice given to people writing shells.
On this basis I would say using either which or command -v in unsound; neither of them are a guarantee that execve(2) will succeed. But like many things done in shell scripts, it's a "good enough" kind of solution that will do the right thing a majority of the time.
… Please try out upgrading your bullseye systems to bookworm now and report issue you encounter”
Roger that!