A steam locomotive from 1993 broke my yarn test

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?

Exec doesn't know about shell aliases. Only what's in the $PATH.

I liked the shell in MPW (Mac Programmer's Workshop, pre-NeXT) where common commands had both long names and short ones. You'd type the short ones at the prompt, but use the long, unambiguous ones in scripts.

What else should the test runner do?

PowerShell has long commands and short aliases, but the aliases can still shadow executables, e.g. the `sc` alias for `Set-Content` shadows `sc.exe` for configuring services. And you only notice when you see no output and weird text files in the current working directory.

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.

There must be a better way to tell if a repo is a Sapling repo than by running some arbitrary binary, right?

The fact that Jest blindly calls whatever binary is installed as `sl` is downright reckless and that's an understatement. If they need the check, a simple way to avoid the problem would be to install it as a dependency, call `require.resolve()` [0] and Bob's your uncle. If they don't want the bundle size, write a heuristic, surely Meta can afford it. Blindly stuffing strings into exec and hoping it works out is not fine.

[0] https://nodejs.org/api/modules.html#requireresolverequest-op...

Is the full path guaranteed? For example homebrew, snap, and apt might put it all in different places. $PATH is a useful tool.

No. This is not the real problem. There is nothing you can do if your 'bash', 'ls', 'cat', 'grep', etc do something they not supposed to do.

Proper error handling would be helpful though.

Networking crowd probably think it's obvious. Because of things like Cisco cli, or even Mikrotik. Or "ip" cli as well, I guess.

I never bothered to check what's the origin of that pattern.

Finding the full path of sl requires looking at $PATH

For Git one could look for .git/config. There must be something equivalent.

What if the full path is just `/usr/bin/sl`?

In this case not as then you find the wrong sl - you need to know where the correct sl was installed.

Then yopu get the sl there which could be correct.

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.

"That's just, like, your opinion, man". There is another school of thought that postulates that an app should use whatever tools that exist in the ambient environment that the user has provided the app with, instead of pulling and using random 4th-party dependencies from who knows where. If I symlinked e.g. "find", or "python3", or "sh", or "sl" to my weird interceptor/preprocessor/trapper script, that most likely means that I do want the apps to use it, damn it, not their own homebrewed versions.

> a simple way to avoid the problem would be to install it as a dependency

I've seen once a Makefile that had "apt remove -y [libraries and tools that somehow confuse this Makefile] ; apt install -y [some other random crap]" as a pre-install step, I kid you not. Thankfully, I didn't run it with "sudo make" (as the README suggested) but holy shit, the presumptuousness of some people.

The better way would have been to have "Sapling CLI" explicitly declared as a dependency, and checked for, somehow. But as the whole history of dev experience shows, that's too much ask from the people, and the dev containers are, sadly, the sanest and most robust way to go.

I think where our opinions differ is what boundaries this logic should cross. When I'm in Bash-land, I'm happy that my Bash-isms use the rest of what's available in the Bash env. When I'm in Node, likewise, as this is an expected and desirable outcome. Where this doesn't sit right with me is when a Node-land script crosses this boundary and starts murking around with things from a different domain.

In general, I would want everything to work by the principle of least surprise, so Node stuff interacts with Node dependencies, Python does Python things, Bash does Bash env, etc. If I need one to interact with the other, I want to be explicit about it, not have some spooky action at a distance.

Ive taken entire web farms offline due to an unexpected expansion of a command on a Cisco load balancer.

The command in question was:

    administer-all-port-shutdown 

(Or something to that effect —it’s been many years now)

And so I went to log in via serial port (like I said, *many years ago so this device didn’t have SSH), didn’t get the prompt I was expecting. So typed the user name again:

    admin

And shortly afterwards all of our alarms started going off.

The worst part of the story is that this happened twice before I realised what I’d done!

I still maintain that the full command is a stupid name if it means a phrase as common as “admin” can turn your load balancer off. But I also learned a few valuable lessons about being more careful when running commands on Cisco gear.

Theoretically you could do this in Linux by calling /usr/bin/sl or whatever - but since various distros put binaries in different places, that would probably cause more problems than it could solve.

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.

Completely understandable, it's just... it's just not in the cards. A large part of UNIX ecosystem has not, historically, been kind to this view. Remember autotools/autoconf, makefiles with DESTDIR, and all that similar jazz? People genuinely proposed that stuff as the solution for the management of ambient dependencies. And it takes just one slip up of "shelling out" (hopefully it's actually "forking off", not literally shelling out) for all kinds of funny business re-appearing again — and don't even start on the /lib and .so management.

Because you know what you installed and so which sl to use.

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.

In that case it is a large security risk as well as it does not work as per the article

.git will be a file and not a directory, if you are in a submodule or a worktree.

You just illustrated why trying to assume the functionality of a third-party app instead of calling it creates even more bugs.

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.