Conversation

Notices

1. Embed this notice
   mcc (mcc@mastodon.social)'s status on Wednesday, 21-Aug-2024 07:32:46 JST mcc

   I have this SD card I keep plugging in and yanking, and when it's plugged in I have a prompt in the directory `/media/mcc/3930-6663/Cores/agg23.RISCV`. And if I yank the SD card then plug it back in, that directory is no longer mounted due to being yanked— I `ls` to list the files & it gives an error. So to make it work again, I have to `cd .` which is a Linux command equivalent to "go to the current directory". Normally it's a no-op but in this case, it causes it to correct pwd to the new mount

   • Embed this notice
     Glyph (glyph@mastodon.social)'s status on Wednesday, 21-Aug-2024 07:32:45 JST Glyph

     in reply to

     • Julia Evans
     • Irenes (many)

     @irenes @mcc @b0rk even ignoring shells though, “getcwd” returns a string, and its “see also” is just malloc(); it doesn’t seem like there is a “give me the current directory as an open file descriptor” or something similar. And this behavior at least *implies* that opendir(“.”) would not do that either

   • Embed this notice
     Irenes (many) (irenes@mastodon.social)'s status on Wednesday, 21-Aug-2024 07:32:45 JST Irenes (many)

     in reply to

     • Glyph
     • Julia Evans

     @glyph @mcc @b0rk and then there's the subtle differences between the semantics of syscalls and the semantics of the libc wrappers around them...

     anyway yeah there's definitely some explanation for this that wouldn't be too hard to find by reading all the sources. we're not sure we want to, it feels cooler as magic

   • Embed this notice
     Chris Siebenmann (cks@mastodon.social)'s status on Wednesday, 21-Aug-2024 07:32:45 JST Chris Siebenmann

     in reply to

     • Glyph
     • Julia Evans
     • Irenes (many)

     @irenes @glyph @mcc @b0rk The kernel tracks the current working directory as an internal object reference, but Linux usually has a name for it. Shells often separately track a name for it (often visible as $PWD), and sometimes perform operations like 'cd ..' by manipulating the name. So if /u/cks is a symbolic link to /h/281/cks and you do 'cd /u/cks', such a shell may implement 'cd ..' so you wind up in /u, instead of /h/281. For many people this better matches their expectations.

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Glyph (glyph@mastodon.social)'s status on Wednesday, 21-Aug-2024 07:32:46 JST Glyph

     in reply to

     • Julia Evans

     @mcc I have seen this sometimes and it implies something interesting about the concept of “working directory” that I’ve never fully understood. In most other ways it looks like the kernel thinks of it as a string, but it clearly doesn’t. I wonder if @b0rk has something that explains this?

   • Embed this notice
     Irenes (many) (irenes@mastodon.social)'s status on Wednesday, 21-Aug-2024 07:32:46 JST Irenes (many)

     in reply to

     • Glyph
     • Julia Evans

     @glyph @mcc @b0rk the thing to keep in mind is that shells store it as a string on the userspace side of things, in addition to the kernel structures. the shell won't rewrite parameters to external commands, but cd is a shell builtin (necessarily so). that's likely part of the magic in why this works