[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] [[!tag open_issue_glibc open_issue_hurd]] [[!toc]] # IRC, freenode, #hurd, June (?) 2010 is there a way (POSIX or Hurdish) to get the corresponding file name for a fd or a hurd port? there is a way marcusb: which one would that be? I forgot there is an implementation in libc realpath has a similar job but that's not what I mean pochu: maybe I am misremembering. But it was something where you keep looking up .. and list that directory, looking for the node with the ID of the node you had .. for maybe it works only for directories yeah pochu: check the getcwd() implementation of libc sysdeps/mach/hurd/getcwd.c _hurd_canonicalize_directory_name_internal  * pochu looks marcusb: interesting though that is for dirs, and doesn't seem to be extensible to files, as you cannot lookup for ".." under a file right oh you already said that :) actually, I am not sure that's correct it's probably correct, but there is no reason why looking .. up on a file couldn't return the directory it's contianed in I don't know the interfaces or the Hurd internals very well yet, but it would look strange to me if you could do that the hurd is strange it sounds like if you could `ls getcwd.c/..` to get sysdeps/mach/hurd/ :-) yep ok. interesting you wouldn't find "ls foo.zip/.." very strange, wouldn't you? I guess not if `ls foo.zip` listed the contents of foo.zip there you go or the other way round: would you be surprised if "cat somedir" would work? I think so. if it did, what would it do? originally, cat dir would list the directory content! in the old unix times I was surprised the first time I typed `vi somedir` by accident and some early BSDs * pochu feels young :-) he don't worry, I didn't see those times either technically, files and directories are implemented in the same way in the hurd, they both are objects implementing the fs.defs interface which combines file and directory operations of course, files and directories implement those functions differently marcusb: do you know why this behavior (cat on directories) was changed? # IRC, freenode, #hurd, 2011-07-13 A related issue: rbraun@nordrassil:~$ vminfo $$ | wc -l 1039 any idea why a shell would consume more than 1039 map entries ? (well, not more actually) even the kernel and ext2fs have around 100 (the kernel has actually only 23, which is very good and expected) braunr: I agree that having some sort of debugging information for memory objects et al. would be quite hand. To see where they're coming from, etc. tschwinge: this would require naming objects at the mach level e.g. when creating an object giving it the path of a file for example braunr: I have recently seen something (due to youpi fixing a bug) that bash is doing its own memory management. Perhaps all these are such regions? braunr: For example, yes. what ? ?! braunr: http://lists.gnu.org/archive/html/bug-bash/2011-04/msg00097.html i see Also see email thread starting at [[!message-id "20110714082216.GA8335@sceen.net"]].