Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why bother with argv[0]?

wietzebeukema.nl

Post reply on HN
Print view View original

191–200 of 277 posts

Re: Why bother with argv[0]?

#191

Post by sokoloff »

dataflow wrote: post #39
travisgriggs wrote: post #32

> “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.

> 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 t…

> 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.

Re: Why bother with argv[0]?

#192

Post by ForOldHack »

duped wrote: post #23
mistercow wrote: post #8

Earlier quoted context omitted.

Also if you want a program to call itself, which is sometimes useful, this way lets you actually call the same program, rather than assuming the name and path.

Don't do this - if you (reliably) want the path to the current executable there is no portable way to do it, but on Linux you need to readlink /proc/self/exe and on MacOS you call _NSGetExecutablePath. I forget the API on Windows.

Four cardinal sins of programming: 1. Self modifying code. ( The word 'recalcitrant' comes to mind. 2. calling your own program to execute itself. 3. Interrupting the flow of control with a jump. 4. Non-graceful exit. 5. Renaming 'hack' as 'vi' or 'ps'

Re: Why bother with argv[0]?

#193

Post by ForOldHack »

actionfromafar wrote: post #43
mostthingsweb wrote: post #21

Earlier quoted context omitted.

Maybe to avoid broken links if you move the original files? That's the main benefit of hardlinks vs symlinks in my mind at least.

That can also be a downside, you believe you have moved stuff but now you can have different versions of programs that don't expect that to be a possibility.

If there is a simlink, a hardlink and an executable, all with the same name, which one will it run? Which one will the shell object to? Which one should the shell object to. If a virus/SUID program overwrites a simlink, no problem, but ift it traces the simlink to the executable, and then over writes that...

Re: Why bother with argv[0]?

#194

Post by lilyball »

zabzonk wrote: post #169
PaulHoule wrote: post #159

Earlier quoted context omitted.

The parser in C has to keep track of the symbol table to handle cases like typdef int myint; myint x; which is unusual among programming languages. Sure I used VM on IBM hardware in the 1980s and it was great. I also used timesharing systems on the PDP-8 (what atrocious hardware!), the PDP-11 and the PDP-10/20 in the 1970s. Although the 360 was superior in so many respects (except for the slow interrupt handling) it…

well, that's like saying the compiler when it sees something like: int x; x = 1; it has to keep track of "x". of course it does. what programming languages don't?

The weird thing about C is the syntax does not clearly identify which tokens refer to types and which tokens refer to other things. A statement like `myint x` is only a variable declaration if `myint` is a type, which means in order to identify a variable declaration, you have to know the complete set of named types, so constructing an AST requires keeping track of types.

Re: Why bother with argv[0]?

#195

Post by remram »

> From a 2020s standpoint, this seems highly undesirable, as it makes software less predictable and goes against modern design principles.

This is not an argument at all, this is a statement that arguments exist. What are they?

It's like saying we shouldn't do something because it's "against best practices". I'm asking why are other practices preferred...

Re: Why bother with argv[0]?

#196

Post by ForOldHack »

SoftTalker wrote: post #48
travisgriggs wrote: post #32

> “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.

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.

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

Re: Why bother with argv[0]?

#197

Post by PaulHoule »

lilyball wrote: post #194
zabzonk wrote: post #169

Earlier quoted context omitted.

well, that's like saying the compiler when it sees something like: int x; x = 1; it has to keep track of "x". of course it does. what programming languages don't?

The weird thing about C is the syntax does not clearly identify which tokens refer to types and which tokens refer to other things. A statement like `myint x` is only a variable declaration if `myint` is a type, which means in order to identify a variable declaration, you have to know the complete set of named types, so constructing an AST requires keeping track of types.

Yeah, it's a really weird thing when you look into the yacc grammar of a C compiler.

Re: Why bother with argv[0]?

#199

Post by neonsunset »

Sohcahtoa82 wrote: post #168
Suppafly wrote: post #160

Earlier quoted context omitted.

>These days, Windows Calculator takes up more memory than mIRC. I'd be somewhat surprised if that's actually true, but I haven't used mirc for years (started using hexchat once I was honest about the fact that I wasn't going to pay for mirc) but I think a lot of that is an inherent part of windows development now, basic c# projects with graphics end up being pretty big. Interestingly enough, the new windows calculato…

> I'd be somewhat surprised if that's actually true It 100% is. I launched Calculator and according to the Processes tab in Task Manager, "Calculator" is using 31.2 MB of memory, and mIRC is taking 17.2 MB. That's with Calculator being freshly launched and no input given, compared to mIRC being connected to 1 server and in 8 channels. If I go to the Details tab, then the story it tells is even worse. I include severa…

> I suppose the price you pay for almost guaranteed memory safety and ease of development through abstractions means your base executable memory footprint includes an entire language runtime.

Surprisingly enough memory safety does not come with extra memory usage. Even GC itself is not incompatible with low RAM footprints even with steady allocation rate as can be seen with both .NET GC configurations and Golang.

One source of base RAM footprint is the presence of JIT compiler - JITing, profiling, then JITing again all those methods is not free, and requires more memory pages, page remapping and additional logic in memory.

It's not impactful and is desirable due to JIT advantages on long-running and complex (often server) applications but is noticeable on something like a Calculator app.

Another source of memory usage is the choices taken by a particular GUI framework - this is by far the biggest contributor of memory use. Quite a lot of them take very heavy-handed, WPF-inspired approach. There is nothing inherently wrong with it, but as was demonstrated with very fast and lightweight immediate mode GUI frameworks like Egui, there is a different way to this. I'm looking forward to putting https://www.pangui.io through its paces whenever it releases, or anything that is even remotely like this and is pure C#.

The Calculator itself seems to use quite a bit of C++ code, I have not profiled it, but I can promise you if you write two implementations of an identical ImGUI-based application with idiomatic constructs of C and C#, the memory footprint will be much closer than you think (for an AOT compiled C# version), maybe within ~5-15MiB delta of RAM once you start adding logic and allocating but unlikely much more. There is no inherent limitation within the language and GC themselves that would prevent that from being possible.

Re: Why bother with argv[0]?

#200

Post by kazinator »

yjftsjthsd-h wrote: post #44

So obviously claiming that there's no good reason for process to read argv[0] is either demonstrating the author's ignorance or needs a much stronger defense; I'd be fascinated to hear how they think busybox should work on an OpenWrt box with a 16MB root filesystem. However , I am willing to consider the discussion about whether there could be merit to restricting the ability to write that value; I could imagine a sy…

If hard linking (no symbolic) is used to install the BusyBox commands, then instead of argv[0], BusyBox could use the platform-specific means of obtaining the executable name, and take the basename of that path. On Linux this means /proc/self/exe; _NSGetExecutablePath on Drawin; getexecname on Solaris; GetModuleFilename on Windows; ...
Post reply on HN