[nonameiguess]

> The POSIX-blessed way of finding an executable program is command -v, which is consequently built into most shells. Given the standard alternative, Adams said, "surely no one competent would choose to have a package depend on `which` when a standard POSIX utility can do a better job".

While I can understand having this attitude, a whole lot of package build scripts, not just in Debian, but in the upstreams, rely upon which existing and printing out the path of an executable without a deprecation warning. I would expect a Debian maintainer to realize that. Debian does patch the heck out of upstream packages, but they don't provide everything, and all Debian users are not going to want to go to equal effort to patch all of the build files for packages Debian doesn't provide.

[shadowgovt]

As a political note: saying something like that is a great way to guarantee that if you want to remove `which`, you likely now have a set of engineers who will oppose your attempts to do so.

Those kinds of attitudes pushed me out of open-source engineering and into closed-source, commercial engineering, purely because it's nice to have a boss who can say "Don't talk to your peers like that; it's counterproductive" with some authority.

[scottlamb]

> While I can understand having this attitude, a whole lot of package build scripts, not just in Debian, but in the upstreams, rely upon which existing and printing out the path of an executable without a deprecation warning.

Probably not. The programs should (and likely actually do) parse only stdout. The warning is on stderr.

I find the whole thing pointless, I disagree with Adams that only incompetent people would depend on which, and I expect actually removing /usr/bin/which to be problematic, but I don't expect the warning itself to break much of anything, except maybe blood pressure cuffs...

[a1369209993]

> The programs should (and likely actually do) parse only stdout.

As of today all my (scripts') use of which is going to include '2>&1' or the contextually appropriate equivalent. Fuck Clint Adams.

[sixothree]

Wait. Is the problem here extra _text_ in the output that shouldn't be parsed?

I cannot believe people are parsing text output from other commands in the year 2021. To me that this sounds like incredibly unsafe practice and am just astounded it happens.

[kayodelycaon]

> I cannot believe people are parsing text output from other commands in the year 2021

If you're writing shell scripts, there aren't any other options.

Here's a lovely little snippet to find the current wifi network for a reMarkable 2. If it's "Aardvark", it runs rsync. :)

    iw wlan0 info | grep -Po '(?<=ssid ).*' | tr -d '\n'

Ugly as hell? Yes, but what's the alternative?

Parsing text from a command is a headache, but it works most of the time. There often isn't an API or syscall to get the data you need on a specific system.

My favorite ugly hack is having a Ruby on Rails application write a file to disk so it can be processed by another program using a shell and then picking up the output file after that program finishes.

This requires a lot of cleanup and diligence to keep from leaking files... or you can set up a nightly cronjob using find to locate all of the files created more than a week ago and delete them. :)

Linux and Unix are a pile of hacks. It isn't going to change anytime soon.

[richardwhiuk]

Parsing the bytestream output of another program is the unix way.

[sixothree]

I get that. I'm just surprised it's still considered acceptable.

I feel like even simple JSON would be a better output. Sure, humans would have a problem reading it but that's what shells are for.

[Spivak]

That JSON would be the text output of the command. There are utilities like grep, find, sed, awk, git porcelain, readlink, basedir, which, that write output suitable for machines on stdout and other utilities that write output suitable for humans.

If you want to be a good UNIX netizen then stdout is for machines while stderr is for humans.

[anonydsfsfs]

I've seen this happen as a workaround for the following bug in Dash: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874264

If Dash was POSIX compliant, this wouldn't be necessary, but it isn't, so hacky text parsing is sadly necessary.