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

Path Isn't Real on Linux

blog.danielh.cc

Post reply on HN
Print view View original

51–60 of 120 posts

Re: Path Isn't Real on Linux

#51

Post by codesnik »

ninkendo wrote: post #48
mzajc wrote: post #25

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

I think bash has an alias “rehash” that does the same as hash -r too. But zsh doesn’t have it, so “hash -r” has entered my muscle memory, as it works in both shells. Edit: wrong shell, zsh has rehash, bash does not.

but zsh has "rehash"? for as long as I remember.

Re: Path Isn't Real on Linux

#52

Post by AlienRobot »

amiga386 wrote: post #41
quotemstr wrote: post #27

Earlier quoted context omitted.

The thing is, though, that PATH being a userspace concept is a contingent detail, an accident of history, not something inherent to the concept of an operating system. You can imagine a kernel that does path searches. Why not? There's a difference between something being a certain way because it has to be that way in order to implement the semantics of the system (e.g. interrupt handlers being a privilege transition)…

* 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. :)

Re: Path Isn't Real on Linux

#53

Post by ninkendo »

codesnik wrote: post #51
ninkendo wrote: post #48

Earlier quoted context omitted.

I think bash has an alias “rehash” that does the same as hash -r too. But zsh doesn’t have it, so “hash -r” has entered my muscle memory, as it works in both shells. Edit: wrong shell, zsh has rehash, bash does not.

but zsh has "rehash"? for as long as I remember.

Bah, you’re right! I got it backwards, it’s zsh that has rehash, bash does not. And hash -r works in both.

I guess I’ve been using zsh longer than I thought, because I learned about rehash first, then made the switch to hash -r later. I started using zsh 14 years ago, and bash 20+ years ago, so my brain assumed “I learned about rehash first” must have been back when I was using bash. zsh is still “that new thing” in my head.

Re: Path Isn't Real on Linux

#55

Post by Joker_vD »

Aloisius wrote: post #43
quotemstr wrote: post #9

Earlier quoted context omitted.

Well, execve(2) and execvp(3) are both "system" functions. C (which is already black magic for some people) invokes both by calling into functions exported from libc. If you're not super dorky^Wfamiliar with low-level systems stuff, you might guess that the two functions are implemented in the same place and in the same way. That the latter is just a libc wrapper around the former that does a PATH search is arcane de…

But the man page section tells you which one is is a a kernel syscall (2) and which is a C library function (3)...

Which is the universally known convention everyone is born with inherent knowledge of. Also, people read man-pages.

Re: Path Isn't Real on Linux

#56

Post by klysm »

inlets wrote: post #3

Why would the author think that the PATH environment variable is being used by the kernel? What an odd assumption.

I don't think it's an odd assumption at all! The lines between shell, exec calls, globbing, etc, are very blurry if you don't already know how it all fits together.

Re: Path Isn't Real on Linux

#57

Post by rafram »

latchkey wrote: post #15
LegionMammal978 wrote: post #13

Earlier quoted context omitted.

One thing I was surprised to learn a couple years ago is that users and groups aren't really tracked much by the Linux kernel: they're just numeric IDs that track process and file ownership. So if you setuid() to a user ID that doesn't exist in /etc/passwd or anywhere else, the kernel won't stop you.

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.

Hopefully that user actually doesn’t exist on the second machine!

Re: Path Isn't Real on Linux

#58

Post by macrocosmos »

ninkendo wrote: post #53
codesnik wrote: post #51

Earlier quoted context omitted.

but zsh has "rehash"? for as long as I remember.

Bah, you’re right! I got it backwards, it’s zsh that has rehash, bash does not. And hash -r works in both. I guess I’ve been using zsh longer than I thought, because I learned about rehash first, then made the switch to hash -r later. I started using zsh 14 years ago, and bash 20+ years ago, so my brain assumed “I learned about rehash first” must have been back when I was using bash. zsh is still “that new thing” in…

If there is something nice that one has and one does not have. zsh is the one that has it.

Re: Path Isn't Real on Linux

#59

Post by thayne »

matheusmoreira wrote: post #34
thayne wrote: post #12

Earlier quoted context omitted.

PATH isn't just handled by the shell though. Many (but not all!) of the exec* family of functions in libc respect PATH.

Those functions aren't the real system calls provided by Linux, they're just glibc wrappers with added functionality. Linux kernel execve has absolutely no concept of PATH, it just opens the file at the provided pathname. That's a good thing too, user space might want to customize that stuff.

Sure, but it is also not the same thing as the shell.

Re: Path Isn't Real on Linux

#60

Post by rafram »

inlets wrote: post #3

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!
Post reply on HN