[travisgriggs]

> “Should a program be allowed to behave differently based on its name?”

I don’t see why not. It’s allowed to behave differently based on the arguments that follow it. I personally think the genericity of including the program name itself as one of its own calling arguments is really meta cool.

[SoftTalker]

One other historical reason for this (also the reason that older unix utilities tend to have such short names) is that people often interacted with unix machines over slow terminals or even paper teletypes. Typing "rm" instead of "remove" or "reboot" instead of "systemctl --reboot" was legitimately more convenient.

[Arch-TK]

I mean, it's still more convenient to type `rm` rather than `Remove-Item` when doing day-to-day computer tasks on your computer (yes I'm one of those people who lives in a terminal).

It's also certainly better from a readability standpoint to have `Remove-Item` rather than `rm` in a script.

Likewise, I would much rather type `ls -Al` rather than `ls --almost-all --long-listing` (N.B. --long-listing is not the long option for -l, -l has no long option, I just made up an appropriate name) when listing a directory but would probably appreciate the long form in a script.

I think just like we have long options and short options, it would be helpful to have long commands and short commands.

[im3w1l]

The best name from a readability standpoint is the shortest name you know by heart. So you might actually want to consider who your intended audience is.

[account42]

Exactly. Any for many commands you need to actually know what the command is doing to fully understand it and can't just go by intuition based on the name. So something more natural sounding can actually be more misleading because it tricks you into thinking the name describes the entirety of what the command does.

[ForOldHack]

As someone who started on ASR-33s. I have empathy for Mr Ritchie and Mr Kernigan.

After all, its 50% faster to type a two letter acronym, than a TLA.

https://media.wired.com/photos/59327efdf682204f73696446/mast...

/e

[Too]

If i download a new version of foo and rename my old version to foo_old_backup_2, should foo_old_backup_2 start behaving differently, just because it has a different name? NO THANKS!

A program should be sandboxed from its environment, including how the user started it. How a user names and organizes his files is a matter between the user and the operating system, not something individual program should care about.

[account42]

A lot of programs actually do need support files at specific locations (either full paths or relative to the executable) so you already don't get to abitrarily organize your program binaries any way you want (without adjusting the programs).

[shermantanktop]

It’s the equivalent of the HTTP Host header, with similar utility. But I agree with the author that an OS provided trustable structure is a much better way.

[marcosdumay]

> an OS provided trustable structure

Repeating the OP, your program takes every other parameter from the caller, why do you insist on the executable name to not be set by him too?

Windows defender is the one that is stupid by using it. Every OS has the real executable name in some place, security software should look there instead.

[strawhatguy]

Yes, this is useful for backwards compat too, like bash with an 'sh' mode.

[dheera]

There are also multiple reasons for a program to read its own executable.

- Decompressing and inflating a compressed binary block with a generic decompressor at the top (e.g. a bash or python script with a binary blob at the end)

- Checksumming its own executable (skipping the checksum string) to resist virus infection. Not bulletproof but viruses aren't usually smart enough to circumvent this

[alkonaut]

Really the weirdness isn't that main is invoked with the program name as argv[0]. The weirdness comes not in main() but in execv. Shouldn't execv have just taken the user provided arguments, prepended the program name (as provided by the OS) and then invoke the main function of the program with that array?

The busybox argument or shutdown/reboot explains why the name of a symlinked binary is helpful as argv[0]. But does the busybox/shutdown case explain why the execv lets the user set the argv[0] value to anything other than what the path says?

[MPSimmons]

If not, then busybox is going to need to change a TON

[dataflow]

> I don’t see why not. It’s allowed to behave differently based on the arguments that follow it.

That's missing the point, I think.

The real question here is, is the name of a program really an argument to the program, from the user's perspective? I certainly don't blame users that disagree. It's more difficult for them to change argv[0], and the fact that this is possible is not necessarily obvious to them, nor to their users.

If it helps, think of it like this: imagine the file timestamp was similarly passed as argv[-1]. And that the file inode number was passed as argv[-2]. Would it make sense to change behavior on those too?

[sokoloff]

> is the name of a program really an argument to the program, from the user's perspective?

When I use busybox [invisibly to me], I sure care that it knows whether I called it as "ls" or as "rm" and that it does the operation that I asked it to do.