6 ms·

I suspect the PATH handling change in go/exec is going to bite many people. You can't just keep exec.LookPath("prog") you now have to explicitly say exec

I suspect the PATH handling change in go/exec is going to bite many people. You can't just keep exec.LookPath("prog") you now have to explicitly say exec.LookPath("./prog") to find prog in the current directory. The os/exec docs have more info on how to error handle this correctly.

morelisp 4y ago
Conversely, as someone who has written a lot of code using LookPath I was shocked (like, actually gasped) to learn in these release notes that it ever did the old behavior, and now need to go check several projects for security issues. Edit: checking the actual os/exec docs instead of the release notes, it’s actually not as bad as it sounds. What the change actually seems to be is that relative paths are now ignored even if they are in $PATH.
- LukeShu 4y ago
  On Unix, it only did the old behavior if you explicitly had "." in your PATH (same as all other programs doing path lookup). The original (1979) default PATH included ".", but it's been considered a bad practice since the mid 1980s, and no modern Unixes include it in the default PATH. So for most Unix users, this is a no-op change. But this is a change on Windows, where bad practices stick around because backward compatibility. (Lots of things would break if cmd.exe changed; but fortunately they fixed this in PowerShell.)
  - pjmlp 4y ago
    I am quite sure that until the early 2000's it was configured by default in many UNIX deployments, and I did use many flavours of it, starting with Xenix in 1992.
    - LukeShu 4y ago
      For sure; by the late 2000s I was still seeing it, but it was fairly uncommon by then. When I said "considered a bad practice since the mid 1980s" I was specifically meaning since Grampp & Morris 1984[1]. It definitely continued to be common for decades after that. I remember lots docs that told you to run "configure" where now they'd tell you to run "./configure", but the docs tended to lag behind the actual change to the default PATH. [1]: https://people.engr.ncsu.edu/gjin2/Classes/246/Spring2019/Security.pdf https://people.engr.ncsu.edu/gjin2/Classes/246/Spring2019/Se...

morelisp 4y ago

Conversely, as someone who has written a lot of code using LookPath I was shocked (like, actually gasped) to learn in these release notes that it ever did the old behavior, and now need to go check several projects for security issues. Edit: checking the actual os/exec docs instead of the release notes, it’s actually not as bad as it sounds. What the change actually seems to be is that relative paths are now ignored even if they are in $PATH.

LukeShu 4y ago
On Unix, it only did the old behavior if you explicitly had "." in your PATH (same as all other programs doing path lookup). The original (1979) default PATH included ".", but it's been considered a bad practice since the mid 1980s, and no modern Unixes include it in the default PATH. So for most Unix users, this is a no-op change. But this is a change on Windows, where bad practices stick around because backward compatibility. (Lots of things would break if cmd.exe changed; but fortunately they fixed this in PowerShell.)
- pjmlp 4y ago
  I am quite sure that until the early 2000's it was configured by default in many UNIX deployments, and I did use many flavours of it, starting with Xenix in 1992.
  - LukeShu 4y ago
    For sure; by the late 2000s I was still seeing it, but it was fairly uncommon by then. When I said "considered a bad practice since the mid 1980s" I was specifically meaning since Grampp & Morris 1984[1]. It definitely continued to be common for decades after that. I remember lots docs that told you to run "configure" where now they'd tell you to run "./configure", but the docs tended to lag behind the actual change to the default PATH. [1]: https://people.engr.ncsu.edu/gjin2/Classes/246/Spring2019/Security.pdf https://people.engr.ncsu.edu/gjin2/Classes/246/Spring2019/Se...