q: How to distinguish Sapling from 🚂 Steam Locomotive?

[vegerot]

I know what you're thinking.

Wasn't April Fools a week ago?

I can assure you this Issue is no jest. We are having a problem with some tools that support Sapling where they don't work properly on systems with Steam Locomotive 🚂 (also called sl).

My question is: how can we distinguish between systems that have Sapling installed or 🚂 ?

ideas:

• sl --version shows "Sapling ..." 🚂 --version just shows the 🚂
• check man sl inconsistent, not portable with Windows
• set a timeout on commands invoking sl slow
• walk up the directory tree and look for .sl directory before invoking sl. Maybe, but this is slow
• check binary sizes. Sapling is 50Mb and 🚂 is 34k. We can simply check if sl > 1Mb

I like the last solution best, but would need to resolve symlinks, etc.

🤡

[vegerot]

related: https://github.com/facebook/jest/issues/14046, https://github.com/facebook/jest/pull/14061

[strager]

I don't see anything in the 🚂 source code which would let us easily detect it. =\

[strager]

Maybe Sapling could distribute two executables: sl and sapling. The latter could be used by scripts or at least feature detection. (sapling could just be a symbolic link to sl, or vice versa.)

[vegerot]

worst idea: the whole point of installing 🚂 is to troll yourself. If you have decided to subject yourself to it, then you deserve what’s coming for you.

The main downside is that in Jest it doesn’t randomly turn your whole screen into a 🚂, it just hangs and prints a weird error message. imo if Jest took over your terminal with a 🚂 animation I would be okay with that, because you installed 🚂 and it’s your fault. However, if someone installed 🚂 two years ago and forgot about it, it’s going to be really hard for them to figure out why their test runner is broken

[strager]

if someone installed 🚂 two years ago and forgot about it, it’s going to be really hard for them to figure out why their test runner is broken

It sounds like Jest's error reporting needs to be improved.

[dvanoni]

if someone installed 🚂 two years ago and forgot about it, it’s going to be really hard for them to figure out why their test runner is broken

I can confirm that it was indeed very hard for me to figure out what was going on. I lost hours to this. 😅

[SimenB]

FWIW, I think it's a good idea to distribute a "full" name version. Like yarn is both yarn and yarnpkg. But that doesn't really solve the underlying issue

[SimenB]

if someone installed 🚂 two years ago and forgot about it, it’s going to be really hard for them to figure out why their test runner is broken

It sounds like Jest's error reporting needs to be improved.

How so? AFAICT, if we cannot detect if sl is sapling or not, there's no proper solution I see to this that doesn't involve guessing, crossed fingers, random timeouts and/or a combination of them. I'd love to be proven wrong, tho 😀

[vegerot]

Good point. @sTRAGER how did you mean "improve Jest's error reporting"?

[vegerot]

@sTRAGER's idea to also ship a sapling binary will help for Windows too, since we could just distribute sapling since sl is a built-in Powershell alias for Set-Location (i.e. cd)

[SimenB]

Our attempt is to detect if the first character of the command is attempting to clear the screen when running sl root - then we're assuming it's steam locomotive: https://github.com/jestjs/jest/pull/15053

I'd still like to see a sapling alias to reduce ambiguity, tho.

[vladh]

I came across this issue as something humorous, so sorry if I'm misunderstanding the requirements, but the Steam Locomotive sl can be detected in Node.js by searching for part of the string making up one of the train cars:

const TRAIN_CAR_PATTERN = "|  |_| |_| |_| |_| |";
const fs = require('fs');
const sl = fs.readFileSync('./sl');
const isSteamLocomotive = sl.includes(TRAIN_CAR_PATTERN);

This has the advantage of not requiring you to run sl. Performance could be further improved by not reading the whole binary into RAM in one go.

[Daniel15]

searching for part of the string making up one of the train cars

@vladh The issue with that implementation is that the Sapling executable is around 80MB. The Steam Locomotive executable (at least the current release on Debian) is 25KB, and the string you're looking for is around offset 0000:41AE (~16KB into the file) so reading only the first 20KB would probably be fine. Actually, just checking the file size would be fine too.

Alternatively, it could run ldd on the executable and look for imports that only one of them uses. For example, Sapling imports libstdc++.so.6 but Steam Locomotive doesn't as it's written in C.

There's been barely any new releases of Steam Locomotive (Debian's only had one major version upgrade, from 3.03 to 5.02, in the past 25 years: https://metadata.ftp-master.debian.org/changelogs//main/s/sl/sl_5.02-1_changelog) so it should be OK to rely on it staying pretty constant.