91–100 of 120 posts
Earlier quoted context omitted.
If I have a file on machineA with uid10001 and I copy the file to machineB, I might want it to retain that uid, but it shouldn't matter to machineB that it doesn't map to a real user.
You’ll see this observation all the time building containers.
Why would strace cat be useful here? By the time cat runs, it was obviously already found. It is basic knowledge that PATH is used by a command interpreter to locate the pathname of binaries. This is true for Window's cmd.exe as well. I never heard of a system where locating files for execution was performed by a kernel.
In the [exec][1] family of POSIX functions, if the command path doesn't contain a slash, then it's looked up in the PATH. > If the file argument contains a slash character, the file argument shall be used as the pathname for this file. Otherwise, the path prefix for this file is obtained by a search of the directories passed as the environment variable PATH [...] [1]: https://pubs.opengroup.org/onlinepubs/009695399/f…
Earlier quoted context omitted.
> Also worth understanding is that programs aren't generally invoking system calls directly They don't generally do that but they absolutely can. I wrote a Lisp interpreter that does just that. It's completely static, has zero dependencies and talks to the kernel directly. The idea is to implement every primitive on top of Linux, and everything else on top of the primitives. From the kernel's perspective, every progr…
My use of "blurry" is because you asserted a clear boundary between user and kernel space. While I agree that this boundary is well-defined, it is indeed "blurred" (made less clear) by the glibc function wrappers and vDSO injected functions. Because the glibc library is a system library and the vDSO is a blob of library code mapped in the kernel. It's not a simple interrupt to context switch and return when complete…
Fun fact: if you've ever had bash (or another shell) complain that a file doesn't exist, even though it's on $PATH, check if it's been cached by `hash`. If the file is moved elsewhere on $PATH and bash has the old path cached, you will get an ENOENT. The entire cache can be invalidated with `hash -r`.
Wtf. TIL about hash.
e.g.
hash java 2>/dev/null || printf "java command not available\n"Why would the author think that the PATH environment variable is being used by the kernel? What an odd assumption.
Unnecessarily rude. There was also a time when you didn’t know this. I can guarantee it!
It's not about knowledge, but about assumptions. The title and conclusion hint that there are some obvious assumptions, but these are not detailed. Maybe author assumed that because of the ubiquitous use of PATH across shells, it had to be managed centrally.
The title is nonsense. PATH is the name of an environment variable (a Real Thing(TM) ) which lists a set of directories to search for an executable. It is used by shells (including those running on Linux) to locate an executable when the full path to the executable is not supplied by the user. This is needed because the exece()/execve() [2] kernel system call is unaware of things like environment variables so it will…
It's real in GNU/Linux tho...
legitimately, if you're interested try writing a shell, your own libc, an elf loader even. It's fun! C is good and cool!
Why would the author think that the PATH environment variable is being used by the kernel? What an odd assumption.
Why not? Every executable is started with execve(2) syscall which takes an array of the environment variables that the kernel use to reset the process's environment variables it inherited from its parent, so obviously the kernel has full knowledge of the environment variables of all of the processes in the system. Now, there is a reason why kernel actually does not have such knowledge, but it's not at all unreasonabl…
https://wiki.archlinux.org/title/Domain_name_resolution
Earlier quoted context omitted.
* in Linux, the kernel is responsible for accepting a list of execve(2) argument-words Yes it does, but the more surprising thing is (coming from AmigaOS with its dos.library function ReadArgs()) that the shell does this . The shell is also responsible for argument expansion - madness! On AmigaOS, when you type "delete foo#? force", the shell passes the entire command line to the delete command. The delete command ca…
Username checks out. I think one of the most surprising things I learned about bash is that you can do this: touch ./-rf rm * And now you have rm -rf'd. :)
I often wish there was a convenient way of doing such an operation in the shell: if path start with "/", leave it, otherwise prepend "./"