Hacker News Reader

Comment by grumpydba | Hacker News Reader

Sorry but one can never be too harsh when reading "rm /bin/sh" in a shell script.

Was there ever a stage in your development where you might have done something like that? This is a rhetorical question because we were all there at some point - even if it was age 8 with a first computer.

If people are displaying good intentions, and not wildly ignoring a load of clear instructions, then engaging with them will have a much greater chance of producing an educated, productive member of the community, and the more of those the better.

Agreed in general, but also, your argument rests on likening Microsoft to an eight year old using their first computer.

Microsoft surely has the means to hire someone who is not an eight year old using their computer for the first time.

Microsoft is a very big company, with everything from interns and developers only with Windows experience through to seasoned nix developers.

This error is actually a good thing from point of view - it's an anecdatum that the whole* company is engaging with open source, not just the bits that know it well. This is something we should encourage and educate. The advantage of educating someone at Microsoft as that their institutional knowledge will persist some fraction of it, so that the next person that comes along is less likely to have issues.

Two words: code review.

Also it's not just a silly commit that was made on github but an actual software release. Any other software developer would be (and have been) mocked just as hard.

I've made many mistakes in my life but I always had enough respect for technology to not yank out parts of a system which I did not understand.

I've always had enough interest in technology to be willing to yank out parts of a system which I did not understand - to see what breaks, and through that, gain understanding.

That said, I'm pretty sure the original author knew and understood exactly what they were doing - writing a dirty hack.

Did you often yank out parts of other people's systems which you did not understand?

Only when I didn't understand the full impact of the hack I used.

> to yank out parts of a system which I did not understand - to see what breaks, and through that, gain understanding.

On your development machine or on machines of other people all around the world? You can also gain understanding from the later, too.

> Was there ever a stage in your development where you might have done something like that?

I think I would have done a little bit of reading. I also think it's the norm.

> Was there ever a stage in your development where you might have done something like that?

I'm still willing to write worse! As a temporary hack with a JIRA issue tracking it, to unblock work, and with the intention of fixing it quickly, but still willing nonetheless.

Meanwhile the code blocks on this website lose their scrollbar and pop atop everything if you hover over them, making it near impossible to scroll right through some kind of abuse of JavaScript. Why?!? Shall I snark about incompetence too? I can't even rationalize this one to myself as a means of unblocking development like I can with the packaging hack!

The great thing about those early machines ( Apple ][+ ) is that the dynamic programming language was the OS and was the REPL and that was all in ROM, so you could tinker around to your heart's content and hit the Reset button if you got stuck. That's a context that's just fine for learning. Packaging for archives installed on other's machines aren't that kind of context.

A kid gets to play in a playroom with some toys, not in a surgical theater or a machine shop.

Yes, it was years before I even thought of applying for a developer position. I don't suppose that's the bar to clear for a company of Microsoft's stature, even if it's the work of a fresh intern.

On a related note, I saw this piece of code in a vendor's install script. Not a Debian package, but an executable install script. One of the environment variables has been censored to anonymize the vendor, but everything else is verbatim.

    # Delete & recreate directory <BLAH>/Patches/<patchLevel>/
    # This will confirm write access to BLAH_HOME
    rm -rf $BLAH_HOME/Patches/${PATCH_VERSION}_${PATCH_LEVEL}
    mkdir -p $BLAH_HOME/Patches/${PATCH_VERSION}_${PATCH_LEVEL}

This is horryfing. No checking the contents of the environment variables. No checking the return codes. WTF.

(and IIRC if you google the snippet, you can find where a coworker of mine posted it to Reddit to lampoon it)

Edit: Just nevermind. I don't want to be the target of this hate train.

It's not a requirement for /bin/sh to point to bash, only that it be a POSIX shell. The user might have chosen "dash" instead, and the one guy out there who doesn't have "bash" installed might find his system no longer boots.

In Debian, bash is an essential package. You can assume it's always installed.

You can make assumptions like that if the consequences are not serious. In this case boot fails next time if your assumption is wrong.

https://xkcd.com/1132/

"Essential" is not some arbitrary assumption, but a term of art specific to Debian Policy, and a flag applied to specific packages:

Essential is defined as the minimal set of functionality that must be available and usable on the system at all times, even when packages are in the “Unpacked” state. Packages are tagged essential for a system using the Essential control field. The format of the Essential control field is described in Essential.

https://www.debian.org/doc/debian-policy/#essential-packages

Diversions are addressed in 3.9: https://www.debian.org/doc/debian-policy/#maintainer-scripts

Debian Policy, generally, tells package maintainers, not users, what they may or may not do. Several classes of conflict are listed in the document; Microsoft's scrips violate multiple requirements.

The goal and result of this ststem, arrived at over 21 years collaborative development (Policy was first published in August 1996) is a system which provides well over 60,000 packages and behaves surprisingly robustly from the user-administrator's perspective. Which is to say, there are few surprises.

Microsoft have violated multiple Policy requirements. This is considered a release-critical bug in distro packages for very good reasons.

OK, fine, then don't add it to the Depends field. But don't replace randomly things with a symlink to bash just because it's installed. If the scripts fail because /bin/sh is not bash, update your fsckin' broken shee-bang line.

Not necessarily, imagine for example an embedded OS with only dash or busybox based on Debian.

Also, even with bash installed, bash doesn't always behave like sh does.

A common example is echo:

With /bin/sh on an OpenBSD:

>>>

kakwa@openbsd ~ sh -c 'echo "print\n"'

>>>

With /bin/dash (aka /bin/sh on Debian)

>>>

kakwa@debian dash -c 'echo "print\n"'

>>>

This is consistent so far.

But, now, with /bin/bash

>>>

kakwa@debian ~ » bash -c 'echo "print\n"'

print\n

>>>

That's why I tend to use printf more than echo in my shell scripts.

Also, I'm not a big fan of what RHEL/CentOS/Fedora does symlinking /bin/sh and /bin/bash. It blurs the line between bash and sh, which results a lot of scripts with a /bin/sh shebang containing bashism.

Uh, I find unrelated software messing with my shell potentially catastrophic.

We absolutely blacklist software pulling crap like this - it is a loud, blinking demonstration that the packager is incompetent and will do other, potentially less obvious dangerous things out of ignorance or impatience. Or is there a darker explanation? Untrustworthy, in either case.

Aside from the fact that it leaves a window where there is no /bin/sh on the system, because it is not using atomic replacement, that is not what the script is doing. This is a Debian package. /bin/sh has been the Debian Almquist shell for almost three quarters of a decade at this point.

* https://lists.debian.org/debian-release/2007/07/msg00027.htm...

* https://wiki.debian.org/BootProcessSpeedup#Using_a_faster_sy...

* https://wiki.debian.org/DashAsBinSh

* https://wiki.ubuntu.com/DashAsBinSh

* https://wiki.ubuntu.com/DashAsBinSh/Spec

Reminder for myself: the right level to respond is the minimum level which will trigger a correction.

https://www.youtube.com/watch?v=OkebMyDvmxs

Search also Jordan Peterson on how to tickle a baby.

Reply on news.ycombinator.com