[HN Gopher] The case of the mysterious --help directory (2020)
       ___________________________________________________________________
        
       The case of the mysterious --help directory (2020)
        
       Author : panic
       Score  : 80 points
       Date   : 2022-01-30 05:33 UTC (17 hours ago)
        
 (HTM) web link (leahneukirchen.org)
 (TXT) w3m dump (leahneukirchen.org)
        
       | tedunangst wrote:
       | Why does zsh want to know where mkdir came from?
        
       | frazbin wrote:
       | Yeah I figured it was shell customization gone awry early on,
       | with 'mkdir --' in the mix. But if they'd figured that out
       | immediately it wouldn't have been a fun post; busting out some
       | custom unix plumbing tools and showing how cool they are is
       | really what the article is about. Also gotta admit they have a
       | pretty darn fun github.
        
       | moonbug wrote:
       | another datum in the "why you should never customise your
       | environment" argument.
        
         | Severian wrote:
         | Actually it should be: "Customize your environment, but take
         | some damn notes FFS."
        
         | ktpsns wrote:
         | another datum in the "you can fix everything if you can control
         | your environment"
        
         | ironmagma wrote:
         | another datum in the "never support GNU coreutils"
         | 
         | I jest, with full knowledge of the trouble I'm causing.
        
           | mst wrote:
           | Get New Utilities is a double edged sword, much like adding
           | layers of abstraction.
        
       | ironmagma wrote:
       | Didn't push a fix upstream?
        
         | tazjin wrote:
         | My understanding is that this function was in her dotfiles, so
         | by virtue of fixing it there it was fixed upstream.
        
           | ironmagma wrote:
           | That isn't what it sounds like to me.
           | 
           | > Jannis Harder told me that the zsh completion for mkdir
           | would run mkdir --help (to see if it's the GNU variant),
           | which I could verify.
           | 
           | Completions are typically installed as an add-on or as part
           | of a core library of a shell.
           | 
           | I found this line, maybe it's the culprit?
           | https://github.com/zsh-
           | users/zsh/blob/master/Completion/Unix...
        
             | mst wrote:
             | The interesting question here (to me) is what an actual fix
             | would even be - given the proximate trigger was basically
             | "lying to zsh about the argument parsing of the thing you
             | were completing" (and obviously we all lie to software all
             | the time, being a cursed sand herder be like that) I'm not
             | sure how you could make the completion setup in question
             | avoid triggering that problem without being less robust for
             | the majority of users.
             | 
             | (this said more in a spirit of morbid fascination with
             | these sorts of weird interactions than anything else, I'm
             | genuinely unsure if there's a right answer here, only "pick
             | which sort of wrong will be least intolerable for your
             | userbase as a whole")
        
             | LukeShu wrote:
             | > > Jannis Harder told me that the zsh completion for mkdir
             | would run mkdir --help (to see if it's the GNU variant),
             | which I could verify.
             | 
             | > Completions are typically installed as an add-on or as
             | part of a core library of a shell.
             | 
             | Right, but the completions were doing the correct thing for
             | `mkdir`. The problem is that in their dotfiles they told it
             | to use the `mkdir` completions for a command that isn't
             | `mkdir`; and what is correct for `mkdir` isn't correct for
             | that other command.
             | 
             | This fix was to make this edit to their own dotfiles:
             | -compdef mkcd=mkdir         +_mkcd() { _path_files -/ }
             | +compdef _mkcd mkcd
        
       | don-code wrote:
       | For reasons like this, I almost wish software came with a "list
       | of unexpected side-effects of using this software".
       | 
       | Take bash, for instance - each time you run a command (this list
       | is nonexhaustive; I'd love to know others):
       | 
       | 1. If you have a `PROMPT_COMMAND`, it'll be run.
       | 
       | 2. The command will be echoed to your history file.
       | 
       | 3. If you hit <TAB>, arbitrary functions might run (for
       | completion).
       | 
       | I don't know what zsh may do on top of this, but my guess is that
       | it's significantly more than bash. That's not a demerit to zsh -
       | that's exactly what it should do - but visibility would be nice.
        
         | eiginn wrote:
         | In Zsh setting '-x' on an interactive shell will also show you
         | what is executed for prompts, completion, and any hooks
         | (probably other things too)
        
           | gryn wrote:
           | same for bash
        
         | eyelidlessness wrote:
         | For that matter, it would be nice if software with side effects
         | of this sort _disclosed them at runtime by default_. For all
         | its faults, this is something npm gets (partly) right. Partly,
         | in this case, because it does print the commands it runs and
         | their output, but it doesn't tell you _why_.
         | 
         | I'm sure this would be overly verbose for most users, who would
         | likely turn it off, but it would still be educational in terms
         | of the huge set of implicit side effects normal every day
         | software produces.
        
       | broses wrote:
       | That reminds me of a function I have in my environment called
       | `dg` that does `cd` then `ls`. The name `dg` is short for dig,
       | since the name `dig` was taken.
       | 
       | I also sometimes write `2>1` instead of `2>&1` and get a
       | mysterious file named `1` in my current directory. Luckily it I
       | figured that one out pretty quick.
        
       ___________________________________________________________________
       (page generated 2022-01-30 23:00 UTC)