4 ms·

The problem is that `which` behaves differently in many different existing use-cases (sometimes reporting aliases and sometimes not). If POSIX defines the beha

by Taywee 5y ago

The problem is that `which` behaves differently in many different existing use-cases (sometimes reporting aliases and sometimes not). If POSIX defines the behavior, then many existing uses become non-standard, and the existing implementations have to decide to change to become standard and possibly break backward compatibility or remain the same and stay non-standard.

guerrilla 5y ago
In that case, pick the system which is statistically dominant and clone that. That'd be GNU first and FreeBSD second. The standard can be some subset of their behavior.
- capableweb 5y ago
  Or, add a new standard describing the wanted behavior from `which` which everyone is already using, but put it under a new binary name. If it's supposed to show the path for the thing passed in, maybe `where` would make sense.
  - ketralnis 5y ago
    A standards descriptivist is unlikely to agree with "make a new standard so everybody has to change their behaviour"
  - dwheeler 5y ago
    They did do that. It's "command -v".
- gnubison 5y ago
  That’s not usually how standards are supposed to work — a POSIX operating system should not reimplement Linux, it should only have to reimplement what’s portable to existing systems.
  - StillBored 5y ago
    Except POSIX has historically always been the intersection of the major Unix vendors. Which is why its always been the lowest common denominator, and is largely crap as a result. Of course to a certain extend all non defacto-standards suffer from this because invariably one group or the other doesn't want to rework their system to fit the standard so they NAK it.
    - gnubison 5y ago
      POSIX does simplify things, diverging from historical practice, when it’s reasonably the only way to standardize stuff that arguably should be standardized. And the vast majority of scripts are easily converted to POSIX-compliant shell script anyways — it’s certainly not “largely crap”.
  - deleted 5y ago
    [deleted]
jchw 5y ago
The behavior of which on different machines has a meaningful enough common subset that I would argue most people have absolutely no idea that there are this many different implementations. It’s possible this would lead to an undesirable standard that specifies less behavior than it should, but on the other hand, I believe that is easier to improve incrementally rather than all in one bandaid rip.
mjevans 5y ago
Minimally breaking solution 1) Require the output of which in non-interactive environments to conform to the behavior a reasonable shell script author is likely to have assumed the specification was based on observations. In the case of historic 'which' that would be to print the absolute path to an executable without any other arguments, or a specific error message and exit status. 2) Allow __interactive__ shells to deviate from that behavior. E.G. with a warning, with alias information, etc.
- rezonant 5y ago
  This is shockingly obvious and it's sort of crazy that it doesn't seem to be discussed [edit: in the overall discussion not just this thread]
- kjeetgill 5y ago
  I feel like I'm going to be bit when I try commands interactively and then that act differently in a script. I think the current solution is the pragmatic one, don't standardize things you can't pull off standardizing! #!
  - hibbelig 5y ago
    The ls command does this: if output is to a tty then it prints in columns. Many commands add color when the output is a tty. I don’t think it would be a big issue.
    - rolandog 5y ago
      Not the person you replied to, but I hadn't thought about that particular difference and I take it for granted, so thanks for bringing it up!
zaarn 5y ago
The simple solution could be that POSIX defines that if the output has a leading slash, it references a path where the command inputted can be found. Any other output is informational in nature only and has no standard texts.
cryptonector 5y ago
That is NOT a problem. Because which is an external program, it can't know about things like shell aliases and functions, and that's OK because users know it or expect it. Indeed, if you're writing a script then you already know what aliases and functions are in it, and you're only going to be interested in knowing what's outside the script -- which(1) does that just fine. Stop looking for problems to solve where there are no problems. It's a waste of others' time, not just your own. Be respectful of others' time.
seanhunter 5y ago
This was the case for literally all of the unix toolset before Posix came along, and how they solved this exact problem in every other case was to define a common subset (which usually involves almost all the functionality you really actually use most of the time) and make that the standard and everyone implements anything that's missing from the standard into their version and keeps all their existing extensions. That's why on linux you can do 'ps -leAf' or 'ps auxww' and have them do almost exactly the same thing for example.

by Taywee 5y ago

guerrilla 5y ago

In that case, pick the system which is statistically dominant and clone that. That'd be GNU first and FreeBSD second. The standard can be some subset of their behavior.

capableweb 5y ago
Or, add a new standard describing the wanted behavior from `which` which everyone is already using, but put it under a new binary name. If it's supposed to show the path for the thing passed in, maybe `where` would make sense.
- ketralnis 5y ago
  A standards descriptivist is unlikely to agree with "make a new standard so everybody has to change their behaviour"
- dwheeler 5y ago
  They did do that. It's "command -v".
gnubison 5y ago
That’s not usually how standards are supposed to work — a POSIX operating system should not reimplement Linux, it should only have to reimplement what’s portable to existing systems.
- StillBored 5y ago
  Except POSIX has historically always been the intersection of the major Unix vendors. Which is why its always been the lowest common denominator, and is largely crap as a result. Of course to a certain extend all non defacto-standards suffer from this because invariably one group or the other doesn't want to rework their system to fit the standard so they NAK it.
  - gnubison 5y ago
    POSIX does simplify things, diverging from historical practice, when it’s reasonably the only way to standardize stuff that arguably should be standardized. And the vast majority of scripts are easily converted to POSIX-compliant shell script anyways — it’s certainly not “largely crap”.
- deleted 5y ago
  [deleted]

jchw 5y ago

The behavior of which on different machines has a meaningful enough common subset that I would argue most people have absolutely no idea that there are this many different implementations. It’s possible this would lead to an undesirable standard that specifies less behavior than it should, but on the other hand, I believe that is easier to improve incrementally rather than all in one bandaid rip.

mjevans 5y ago

Minimally breaking solution 1) Require the output of which in non-interactive environments to conform to the behavior a reasonable shell script author is likely to have assumed the specification was based on observations. In the case of historic 'which' that would be to print the absolute path to an executable without any other arguments, or a specific error message and exit status. 2) Allow __interactive__ shells to deviate from that behavior. E.G. with a warning, with alias information, etc.

rezonant 5y ago
This is shockingly obvious and it's sort of crazy that it doesn't seem to be discussed [edit: in the overall discussion not just this thread]
kjeetgill 5y ago
I feel like I'm going to be bit when I try commands interactively and then that act differently in a script. I think the current solution is the pragmatic one, don't standardize things you can't pull off standardizing! #!
- hibbelig 5y ago
  The ls command does this: if output is to a tty then it prints in columns. Many commands add color when the output is a tty. I don’t think it would be a big issue.
  - rolandog 5y ago
    Not the person you replied to, but I hadn't thought about that particular difference and I take it for granted, so thanks for bringing it up!

zaarn 5y ago

The simple solution could be that POSIX defines that if the output has a leading slash, it references a path where the command inputted can be found. Any other output is informational in nature only and has no standard texts.

cryptonector 5y ago

That is NOT a problem. Because which is an external program, it can't know about things like shell aliases and functions, and that's OK because users know it or expect it. Indeed, if you're writing a script then you already know what aliases and functions are in it, and you're only going to be interested in knowing what's outside the script -- which(1) does that just fine. Stop looking for problems to solve where there are no problems. It's a waste of others' time, not just your own. Be respectful of others' time.

seanhunter 5y ago

This was the case for literally all of the unix toolset before Posix came along, and how they solved this exact problem in every other case was to define a common subset (which usually involves almost all the functionality you really actually use most of the time) and make that the standard and everyone implements anything that's missing from the standard into their version and keeps all their existing extensions. That's why on linux you can do 'ps -leAf' or 'ps auxww' and have them do almost exactly the same thing for example.