Most active commenters
  • pasc1878(6)
  • Joker_vD(3)

←back to thread

A steam locomotive from 1993 broke my yarn test

(blog.cloudflare.com)
167 points jgrahamc | 13 comments | 02 Apr 25 13:10 UTC | HN request time: 0.001s | source | bottom
Show context
bouke ◴[02 Apr 25 14:35 UTC] No.43557162[source]▶
So the real problem is that Jest just executes to whatever `sl` resolves. The fix they intent to release doesn't address that, but it tries to recognise the train steaming through. How is this acceptable behaviour from a test runner, as it looks like a disaster to happen. What if I have `alias sl=rm -rf /`, as one typically wants to have such a command close at hand?
replies(4): >>43557349 #>>43557468 #>>43557711 #>>43558209 #
blueflow ◴[02 Apr 25 15:02 UTC] No.43557468[source]▶
What else should the test runner do?
replies(2): >>43557612 #>>43557677 #
1. pasc1878 ◴[02 Apr 25 15:14 UTC] No.43557612[source]▶
Use the full path of sl and not rely on $PATH in the same way cron and macOS GUI apps do for I assume this exact reason.
replies(4): >>43557887 #>>43558500 #>>43558696 #>>43560502 #
2. stonegray ◴[02 Apr 25 15:36 UTC] No.43557887[source]▶
Is the full path guaranteed? For example homebrew, snap, and apt might put it all in different places. $PATH is a useful tool.
replies(2): >>43558585 #>>43559161 #
3. charcircuit ◴[02 Apr 25 16:32 UTC] No.43558500[source]▶
Finding the full path of sl requires looking at $PATH
replies(1): >>43559145 #
4. ◴[02 Apr 25 16:40 UTC] No.43558585[source]▶
5. skipants ◴[02 Apr 25 16:51 UTC] No.43558696[source]▶
What if the full path is just `/usr/bin/sl`?
replies(1): >>43559149 #
6. pasc1878 ◴[02 Apr 25 17:34 UTC] No.43559145[source]▶
In this case not as then you find the wrong sl - you need to know where the correct sl was installed.
7. pasc1878 ◴[02 Apr 25 17:34 UTC] No.43559149[source]▶
Then yopu get the sl there which could be correct.
8. pasc1878 ◴[02 Apr 25 17:36 UTC] No.43559161[source]▶
But not in this case where you have two executables with the same name.

You have to know where the tool was installed or else be certain no other sl is on your path.

9. Joker_vD ◴[02 Apr 25 19:23 UTC] No.43560502[source]▶
How would knowing the full path help you anyway? It's either in "/usr/bin/sl", or "/usr/local/bin", or "~/.local/bin", now what?

By the way, believe it or not, POSIX compliance requires existence of only two directories (/dev and /tmp) and three files (/dev/console, /dev/null, and /dev/tty) on the system; everything else is completely optional, including existence of /bin, /etc, and /usr.

replies(1): >>43567698 #
10. pasc1878 ◴[03 Apr 25 10:47 UTC] No.43567698[source]▶
Because you know what you installed and so which sl to use.
replies(1): >>43567880 #
11. Joker_vD ◴[03 Apr 25 11:09 UTC] No.43567880{3}[source]▶
But the sl is not invoked by you. It is invoked by some npm module (a 5-times-removed dependency from any side) which hopes that either there is "sl" in the $PATH and it is the Sapling CLI, or there is no "sl" in the $PATH. This module can't use absolute paths because it does not know how the end user's system looks.
replies(1): >>43571917 #
12. pasc1878 ◴[03 Apr 25 16:17 UTC] No.43571917{4}[source]▶
In that case it is a large security risk as well as it does not work as per the article
replies(1): >>43580073 #
13. Joker_vD ◴[04 Apr 25 09:53 UTC] No.43580073{5}[source]▶
A program invoking some other the program that the user themself consciously have installed on their system (and put into the PATH) is not a security risk per se, it's literally UNIX Way™ working as intended.