LWN: Comments on "Program names and "pollution""

Program names and "pollution"

neilbrown — Fri, 12 Apr 2019 01:08:43 +0000

> And as for V1, there is the "putchar" function.

Was there?? I thought "putchar" was a macro for fputc(c, stdout), but I haven't checked V1. Rules for macro names would be different from those for linker symbols.

Program names and "pollution"

jengelh — Thu, 11 Apr 2019 19:51:49 +0000

>Wasn't it a linker limitation originally? 6 characters per name,

And as for V1, there is the "putchar" function.

Program names and "pollution"

jengelh — Thu, 11 Apr 2019 19:42:47 +0000

>Wasn't it a linker limitation originally? 6 characters per name,

There is the "localtime" call in V7 (at least whatever copy I could grab off github), which is way above 6 characters.

Program names and "pollution"

mgedmin — Thu, 11 Apr 2019 09:14:12 +0000

Wasn't it a linker limitation originally? 6 characters per name, plus C name mangling prepended an underscore for some reason, so _creat was the longest you could have at the linker level.

Program names and "pollution"

karkhaz — Tue, 09 Apr 2019 23:35:35 +0000

You joke, but I'm pretty sure that Android did something similar to the delay thing...but I don't remember the details, maybe somebody else can furnish them. My recollection is that they wanted to force application developers to link against a new incompatible version of some library (maybe libc/bionic?). So they added a startup delay (I guess to _start() or something) and increased the delay every few weeks until the users noticed.

Program names and "pollution"

flussence — Tue, 09 Apr 2019 22:54:18 +0000

Why not both? And to keep things interesting, have them both implement similar functionality, but differ in behaviour just enough to have one completely break when used outside of a completely default setup.

/me glares in pulseaudio's general direction...

Program names and "pollution"

flussence — Tue, 09 Apr 2019 22:43:20 +0000

daemontools and its lineage traditionally have a (cheerfully FHS-ignoring) "/command/" directory for exactly this reason. The idea is service supervisor processes get started with this in their PATH, containing all the service helper binaries (things like start-stop-daemon might be at home in there), and then the services and user sessions under them are run with /etc/profile's PATH as usual, so as to not pollute their namespace.

The choice of directory location is unfortunately vague and didn't age well, but at least it's an attempt.

Program names and "pollution"

mirabilos — Tue, 09 Apr 2019 20:11:18 +0000

There’s always 「dpkg -S $(which programname)」 if you need to figure out where a utility comes from…

Program names and "pollution"

nix — Tue, 09 Apr 2019 15:16:28 +0000

Hm, you could deprecate gracefully by producing a non-interruptible animation of a steam locomotive every time someone types the old names? :P :P

Program names and "pollution"

k8to — Tue, 09 Apr 2019 01:40:14 +0000

This is an entertaining idea. My practical perspective is as a user I would not be entertained to debug this.

Program names and "pollution"

anselm — Mon, 08 Apr 2019 09:01:18 +0000

These two changes/gripes were mentioned by Dennis Ritchie

According to legend, Ken Thompson was once asked what he would do differently if he were to redo Unix from scratch. His answer was “I'd spell ‘create()’ with an ‘e’ at the end.”

OTOH, if your main means of interaction with the computer is a 110-baud teletypewriter, you may be forgiven for wanting to make every character count. In that situation, using “?” as an error message starts making a lot of sense.

Program names and "pollution"

jschrod — Sun, 07 Apr 2019 23:07:05 +0000

YES!!!

And while we're at it:
- Rename creat() to create().
- Clean up that awful abbreviation "pwd" to
have something to do with passwords instead of meaning "print working directory", as any newbie would expect.

On a serious note, it's not always as practical to change established namings even if it would be sensible.

Cheers, Joachim

PS: These two changes/gripes were mentioned by Dennis Ritchie at a conference dinner where I had the occasion to be at the same table. So please don't blame me for bringing them up. :-) :-)

Program names and "pollution"

Karellen — Sun, 07 Apr 2019 20:52:42 +0000

I wonder if a distro like Debian could try that all by itself.

Package all the client commands into /usr/lib/postgresql/, add a "/usr/bin/pgctl" or similar utility which makes "pgctl <command> [args...]" redirect to "/usr/lib/postgresql/<command> [args...]", and then add a postgresql-legacy package which adds symlinks for "/usr/bin/<command>" to "/usr/lib/postgresql/<command>"

Do it in "sid" as soon as the freeze ends after the next release, see what breaks, and revert back to the current system if it's too bad before the following release. That's what sid is for :-)

Program names and "pollution"

tlw — Sun, 07 Apr 2019 00:40:21 +0000

This is what GNU stow is for.

Program names and "pollution"

rossmohax — Sun, 07 Apr 2019 00:13:38 +0000

deprecate gracefully by introducing startup delay of 10 seconds every major release

Program names and "pollution"

zdzichu — Thu, 04 Apr 2019 17:28:41 +0000

pgctl

Program names and "pollution"

perennialmind — Thu, 04 Apr 2019 17:23:29 +0000

Those people are already having to adapt. It's been deprecated in util-linux since util-linux v2.23, released in 2013 and hasn't been built by default since v2.29, released in 2016. After 2016, Debian, Ubuntu and Slackware were the outliers still shipping /usr/bin/pg. After Buster is releases as as Debian 10 this year, it'll just be Slackware.

Program names and "pollution"

perennialmind — Thu, 04 Apr 2019 16:42:03 +0000

Well that's just awful. pg would otherwise be the obvious choice. It's certainly the first thing I'd try tabbing at the console. Actually, thinking back, I think I did exactly that years ago and was peeved to realize what I'd stepped in. Postgres deserves a two-letter namespace prefix. Thankfully most distros have cleared the stinking pile off the path long ago and Debian derivatives will soon.

Whatever anchor they choose, I'll add an alias of my own. pg createuser just feels right.

Program names and "pollution"

simosx — Thu, 04 Apr 2019 13:29:42 +0000

It is really poor CLI usability to create such generic commands.
The Postgress community should act and fix this issue without the need to be told to.

In terms of usability, they use should have a single entry command like "pg" (from PostGress).
The user would need to run "pg" to get a helpful reminder screen with the available subcommands.
If the user wants to perform cluster tasks, they would run "pg cluster" and get the list of "cluster" subcommands.
Like, "pg cluster create", "pg cluster ls", etc.

As it is now, you need to remember "pg_lsclusters", which is wrong in many ways. It is the wrong order of words. "cluster" is plural because otherwise the command would look silly.

In addition, Postgress can provide shell completion (bash-completion) rules to help users with the commands.

It is up to Postgress to plan for a transition and make the CLI commands somewhat better.

Program names and "pollution"

lamawithonel — Thu, 04 Apr 2019 13:25:53 +0000

That's the point of #3. The first-line build system is something the developers control, and doing it there makes sure everyone gets it, be that packagers in the project, distro packagers, or users who compile it themselves. Also, in my experience, a lot of people won't even consider things like removing part of the build, so giving them a way to do it, even if they don't end up using the way provided, helps jolt imagination.

Program names and "pollution"

tzafrir — Thu, 04 Apr 2019 05:37:52 +0000

Debian had a namespace conflict between the older /usr/sbin/node (from package ax25-node , used by amature-radio operators[1]) and /usr/bin/node from the new package nodejs. Should be no conflict between the two, right? But what if you have a nodejs program for managing a ham radio[1]?

[1] Or however this is called.

Program names and "pollution"

david.a.wheeler — Wed, 03 Apr 2019 21:12:42 +0000

At first I thought "A Linux user's $PATH likely contains well over a thousand different commands..." meant "a thousand different directories". That is highly unlikely, and not what the author meant anyway (but I note it in case someone else has that misunderstanding).

Trying to figure out "what package installed this" from just the name is a terrible idea. There are already package management tools that accurately provide this information; please use them. Trying to guess from the name will be wrong too often to be useful.

I think if you are creating new programs it'd be wise to have easily disambiguated names. Not because that should replace a package manager, but because that will avoid a lot of unnecessary heartache and confusion if the same name has multiple meanings.

I think it'd be good if PostgreSQL created synonyms with new non-generic names and used them uniformly in new scripts, while retaining the old (deprecated) names for a long time for backwards compatibility. Not because you're trying to replace a package manager, but because someone who never uses PostgreSQL is likely (sooner or later) to use the same names. If you supported the "old" and "new" names for a long time (say 7+ years), it could be relatively painless.

Program names and "pollution"

rotty — Wed, 03 Apr 2019 17:19:36 +0000

Regarding step 3 (creating a separate build path to build only shims/symlinks to aid packaging), I'd like to add that this seems likely unnecessary for distributions which have a binary/source package separation, such as Debian. Whether to include specific files, and in what package binary package to include them in, is already up to the maintainer. In the case of Debian, the `debian/*.install` files specify exactly that.

This build system feature, though, would probably helpful on source-based systems, though I'm not familiar with those.

Program names and "pollution"

martinfick — Wed, 03 Apr 2019 17:03:07 +0000

It works if you put them in different directories.

Program names and "pollution"

BenHutchings — Wed, 03 Apr 2019 16:42:49 +0000

Sorry about that :-)

Program names and "pollution"

jccleaver — Wed, 03 Apr 2019 15:57:38 +0000

I'm a fan of environment modules, but they're not suited for this unless you really need to segregate employees out.

This really is *primarily* a postgresql problem. I'm hard pressed to think of any conflict or overly-vague script or binary names I've experienced outside of PGSQL other than one conflict with the "maildir" utility back in the early 2000's. Most projects know to keep anything likely to be placed into a $PATH as unique as possible and seem pretty reasonable about it. That's not to say that growth isn't a problem, but that's more a function of Fedora's UsrMove and some people pushing for a conflation of Bin and Sbin than anything else.

One thing I really would like to see though is more use of libexec where appropriate. If these binaries aren't really intended for execution by humans except in unusual, debugging situations, they don't need to be in $PATH. Move them to /usr/libexec/ where they belong.

Program names and "pollution"

kh — Wed, 03 Apr 2019 15:19:09 +0000

Why not create a separate package postgresql-legacy-cmds to put all the deprecated commands in. That way if some end user has a bunch of scripts they don't want to update, and they ignore all the deprecation warnings for a few years, when the commands are actually deprecated, (and this new package is no longer a dependency) all they will need to do with newer systems to fix their scripts is a quick apt-get postgresql-legacy-cmds or equivalent and they can continue to use all their old scripts, but others will not be bothered. Maybe this is already implied or suggested and I missed it.

Program names and "pollution"

rfunk — Wed, 03 Apr 2019 14:56:21 +0000

Fine, call it pgcmd or anything. The specific name (of the command or the directory) isn't important.

Program names and "pollution"

cortana — Wed, 03 Apr 2019 14:48:42 +0000

I'm afraid that would break for people who use util-linux's 'pg' command as their PAGER.

Program names and "pollution"

epa — Wed, 03 Apr 2019 13:54:59 +0000

I imagined that just 'git' would produce a message from the shell saying 'git is a directory but the following subcommands exist: git grep, git pull, ...'

That doesn't work if the main 'git' program is more than just a simple wrapper for subcommands -- if there were some hypothetical 'git -xyz' that did something by itself. And the shell's message would be much more basic than the help text printed by the 'git' binary. But there is always the top-level manual page.

Program names and "pollution"

mathstuf — Wed, 03 Apr 2019 13:19:08 +0000

So `git` needs two `PATH` entries to work? Otherwise `git` would fail because it's a directory…

Program names and "pollution"

geert — Wed, 03 Apr 2019 13:04:56 +0000

I wrote a script "linux-version", which creates a version string from the Makefile in a Linux source tree, and prints it.

Only recently did I discover this was the cause of mysteriously appearing files "/var/lib/initramfs-tools/v." and "/boot/initrd.img-v.".
Apparently Ubuntu already has a command named "linux-version", which it wants to call every time the initramfs-tools package is upgraded...

Program names and "pollution"

lamawithonel — Wed, 03 Apr 2019 10:24:18 +0000

err... 6 should actually be "invert the build option so the symlinks/shims are not built by default," 7 would be "Rejoice when our AI overlords remove all the code to build and test symlinks/shims."

Program names and "pollution"

lamawithonel — Wed, 03 Apr 2019 10:15:27 +0000

Maybe you need more phases than only Deprecation and Removal. The following would be a lot more work, no doubt, but it would give users a lot more options and opportunity to fix things.

1: Move existing commands to pg_* and create symlinks.
1a: (optional) Create a central binary with sub-commands, à la `git` or `systemctl`, and move all the pg_* commands under that. Replace symlinks with shim binaries.
2: Start printing a warning if commands are called by their legacy names, but allowi users to silence the warnings with an option flag.
3: Create a build path to build only the symlinks/shims, and a non-default way to build without them. This gives packagers an easy way to package them separately, and users a way to test without them. It also gives packagers some control over how and when they remove the symlinks/shims.
4: Make deprecation warning silence flags NOOP.
5: Inspired by rfunk's comment, move the symlinks/shims out of $PATH, to something like /usr/share/postgres/bin, and declare them unsupported. Inform users that they can add the new directory to their $PATH if they really need them for some reason, but that you won't accept bug reports against them. Maintain this for at least another major release, possibly several more.
6: Rejoice when our AI overloads remove all the symlinks/shims.

Program names and "pollution"

civodul — Wed, 03 Apr 2019 10:07:09 +0000

Indeed, with Guix and similarly with Nix, readlink -f `which createuser` returns the absolute file name of createuser; its parent directory contains the package name, so I can see that it comes from PostgreSQL.

More generally, Nix and Guix do away with the global program name space that /usr/bin is. You can create environments on the fly with guix environment containing exactly the packages you want, so name clashes become a non-issue.

Program names and "pollution"

epa — Wed, 03 Apr 2019 10:00:42 +0000

+1 to that but maybe also "git foo" could be an alias for "git/foo", if a directory git/ exists in the PATH. Then a lot of these wrapper commands could be tidied up.

Program names and "pollution"

giggls — Wed, 03 Apr 2019 08:34:33 +0000

Hm you do now about pg_virtualenv?

Program names and "pollution"

kandreas — Wed, 03 Apr 2019 08:18:30 +0000

The PostgreSQL project is fine with doing the work. The concern is that we will break tons of end users' scripts and pissing them off. I am one of those arguing in favor of fixing this but I know fixing it will break a ton of third party tools and in house scripts at various companies when we in 3-5 years time pull the plug and remove the legacy aliases. Even with a long deprecation cycle with warnings some people will not update their scripts.

Program names and "pollution"

cpitrat — Wed, 03 Apr 2019 08:10:08 +0000

That was also my very first thought: adding the symlinks alone is useful for discoverability. It doesn't seem to have been discussed !

Program names and "pollution"

cavok — Wed, 03 Apr 2019 07:35:49 +0000

I was also thinking along this line. Make the legacy names be opt-in so that when legacy references are expected it is easy for the admin to get along. This way new users can start with the clean setup and avoid the lock-in.