On 28/06/2019, Ingo Schwarze <> wrote: (...) while the fact that the cwd is a property > of each process is actually fairly obvious in the first place. > What else could it possibly be, in a multi-user system?
Fair enough; I suppose it's one of these things that once you know them, they're obvious, and anything else seems unimaginable. ;) But to imagine something else: Things could have been designed for the shell to run in /bin (its *own* cwd) while *separately* keeping state of a user- and program-cwd, which is what I meant when I talked about nannying and chaperoning programs, etc. However, there is a minimalist and very Unix-like elegance to the actual choice of just using the working directory of the current shell execution environment for that end. I do admire it, and it does make permissions that much clearer. I had just never thought about it before, though it seems so obvious in retrospect. The only thing that now feels less intuitively clear is that there apparently still is a need to have traverse permissions all the way down, as mentioned here for example: <https://askubuntu.com/questions/1106822/directory-has-a-executable-file-mode> >> On the lower level, this particular permission in stat.h standard Unix >> library >> is defined as >> S_IXUSR >> Execute/search permission, owner. >> (...) >> The reason behind that lies in the POSIX definition of EACCES: >> [EACCES] Permission bits of the file mode do not permit the requested >> access, or search permission is denied on a component of the path prefix This would suggest path resolution back from the directory root with every chdir() call, no? Now that I think about it, I'm not entirely sure when traverse permissions (for "upper"/path prefix directories) really come into play. But this is really more of a "I need to learn this" issue and less of a "can OpenBSD's man pages be improved here" issue. Ingo Schwarze <> wrote: > we don't write separate manual pages for shell builtins. > > It was discussed internally whether the chdir(2), getcwd(3), > pwd(1), and ksh(1) manual pages can be improved to make it more > explicit that the current working directory is a process property. > > But the conclusion was that introducing wording to that effect risks > causing other ambiguities, (...) > > So the manual pages remain unchanged. This relates to a long-standing annoyance: When I do `man kill` for example, the manpage shown is for code that won't be what runs when I do `kill <something>`. I suppose the general case is that there can be discrepancies between >> $ which kill >> /bin/kill >> $ type kill >> kill is a shell builtin and perhaps `man kill` too (kill is just an example; the issue generalises). As much as this looks like a problem that wants solving, it's such a long-standing and fundamental issue that I'm not sure what can be done. Is there any sense in adding some checks to man(1) to ensure the "wrong" information is not displayed? An added complication: When users are looking at the respective sections for builtins in `man sh` vs `man ksh`, it may not always be clear which description and behaviour would actually apply. It's also very cumbersome to jump to the correct section e.g. in `man ksh`, even if the user already knows what kind of command and documentation to look for (which is half the battle). One way I sometimes do that is: >> $ man ksh >> G?The following describes/<builtin_name> This obviously isn't ideal, but I have not found any applicable shortcuts. Would it be possible to add some way to make it easier to accomplish the task "show me the documentation of builtin <foo> in man ksh"? |Side note: |The util-linux whereis(1) will, as per `man -k whereis`, |"locate the binary, source, and manual page files for a command", |while OpenBSD's whereis(1) will "locate programs", noting that |>> The whereis command first appeared in 2BSD, but the original version was |>> legally tainted and was not included as part of the 4.4BSD release, such |>> that most of the original functionality was lost. |cf. <https://man.openbsd.org/whereis#HISTORY> |FreeBSD has a version that |>> re-implements the historical functionality that was lost in 4.4BSD. |cf. <https://www.freebsd.org/cgi/man.cgi?query=whereis#HISTORY> |They've apparently had those features back since FreeBSD 2.2.1 (April, 1997), |which would have been not long after those features were removed. They seem |to have rewritten their whereis(1) in 2002: |<https://svnweb.freebsd.org/base/release/12.0.0/usr.bin/whereis/whereis.c?revision=341707&view=markup> |How suitable any of this might be for OpenBSD I'm not in a position to say. Anyway, in an ideal world, typing man <command> would always show the man page actually relevant to what the box would do if the user typed <command> at the prompt. I don't know how this could be solved though; I'm just noticing that there's much inconsistency and considerable possibility for user confusion in that area. |As another aside: |On Ubuntu (and probably Debian), when the user types a command name that does |not correspond to any program actually installed, but that *does* correspond |to an executable present in a .deb package present in currently configured |repositories, the system will recommend that package (sometimes several |packages) and helpfully print what the user would have to type to install said |package(s). It does some fuzzy matching too and it's surprisingly easy to get |used to that, however I'm unsure if such comforts would be developer-desirable |or easy to implement cleanly with OpenBSD packages(7), and I just *hope* |Ubuntu is doing this without phoning home, which latter it really shouldn't do, |but knowing of Ubuntu and zeitgeist, I'm not sure: | |>> ubuntu$ teh | No command 'teh' found, did you mean: | Command 'tth' from package 'tth' (universe) | Command 'tex' from package 'texlive-binaries' (main) | Command 'tesh' from package 'libsimgrid-dev' (universe) | Command 'tea' from package 'tea' (universe) | Command 'te' from package 'interchange' (universe) | Command 'feh' from package 'feh' (universe) | Command 'tel' from package 'orville-write' (universe) | Command 'the' from package 'the' (universe) | Command 'tee' from package 'coreutils' (main) | teh: command not found |>> ubuntu$ brown | No command 'brown' found, did you mean: | Command 'frown' from package 'frown' (universe) | brown: command not found |>> ubuntu$ fox | The program 'fox' is currently not installed. You can install it by typing: | sudo apt install objcryst-fox |>> ubuntu$ jumps | jumps: command not found |>> ubuntu$ emacs | The program 'emacs' can be found in the following packages: | * emacs24 | * emacs24-nox | * e3 | * emacs24-lucid | * jove | Try: sudo apt install <selected package> |The five behaviours (that I know of) on display, in order: multiple fuzzy |matches, single fuzzy match, exact match, no match, multiple exact matches. To end on a positive: Can I add how much I appreciate that OpenBSD hard-links help(1) to man(1), and that man will default to `man help` when called as help? This elegant way of having OpenBSD respond to `help` is really n00b-friendly. Thanks for your time, Ian
