1. 53
  1.  

  2. 19

    [the man directory] contains the generated man pages. Because it’s adjacent to bin (which is on my path) the man program automatically finds the man pages as expected.

    Whoa! I just tried this: my $PATH contains ~/dotfiles/bin, so I creating a simple text file ~/dotfiles/man/man1/mytest.1, and typed man mytest, and it worked! Finally I can easily create & install man pages, rather than implementing a response to a -h/--help flag.

    1. 1

      I just discovered this poking around in the manual page for manpath, or whatever the man config file is. It’s pretty neat! You can also set MANPATH.

      1. 1

        So, I actually also tried, yesterday, to find the docs for the ‘$PATH -> man path’ auto-mapping in the manpage; but unlike you, I couldn’t find it. If you have an occasion, could you perhaps post the man page / excerpt you found, so I can know what I overlooked? No need to reply if you don’t have an occasion.

        I ran man 1 man 1 manpath 5 manpath and read through those manpages; and I read through the comments in /etc/manpath.config; but the closest I could find was set of directives like MANPATH_MAP /bin /usr/share/man, which only map specifies specific man dirs to specific PATH dirs. I couldn’t find anything documenting the rewriting rule ‘for any directory in $PATH, look in a sibling directory called man.’ Pointers welcome!

        1. 3

          Linux man pages do not describe this, but freebsd manpages do.

          1. 2

            On Linux, old man (1.6g) documents this as well, only modern man-db does not.

          2. 1

            I have no idea what I was thinking about with the PATH -> MANPATH conversion, lol

            However, I do know that you can set $MANPATH with a leading : to have it append directories to the auto-generated MANPATH, or with a trailing : to have it prepend them. So that’s what I do.

      2. 2

        I think this article misses the rather important section which could be relevant to the title saying “small CLI programs”: how can you transform that whole Common Lisp codebase into single, statically linked, standalone executable binary which could work on remote hosts being copied over SSH without gazillions of uneeded dependencies?

        1. 7

          how can you transform that whole Common Lisp codebase into single, statically linked, standalone executable binary which could work on remote hosts being copied over SSH without gazillions of uneeded dependencies?

          That’s… pretty much what it’s doing?

          sjl at alephnull in ~/src/dotfiles/lisp on default!?
          ><((°> touch batchcolor.lisp
          
          sjl at alephnull in ~/src/dotfiles/lisp on default!?
          ><((°> make
          mkdir -p bin
          ./build-binary batchcolor.lisp
          mv batchcolor bin/
          mkdir -p man/man1
          ./build-manual batchcolor.lisp
          mv batchcolor.1 man/man1/
          
          sjl at alephnull in ~/src/dotfiles/lisp on default!?
          ><((°> scp bin/batchcolor vm:batchcolor
          batchcolor                                   100%   42MB  59.4MB/s   00:00
          
          sjl at alephnull in ~/src/dotfiles/lisp on default!?
          ><((°> ssh vm
          
          vagrant@vm:~$ echo 'test 1234 test 1234 test 5678' | ./batchcolor '[0-9]+'
          test 1234 test 1234 test 5678
          
          vagrant@vm:~$ ldd batchcolor
                  linux-vdso.so.1 (0x00007ffe7f369000)
                  libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff4822da000)
                  libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff4822b9000)
                  libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff482136000)
                  libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff481f75000)
                  /lib64/ld-linux-x86-64.so.2 (0x00007ff482542000)
          

          It does depend on a few C libraries – if you want to remove even those you’ll need something like this.

          1. 3

            This article is not missing anything, it is what it is. If you did not find information you were looking for, then asking a question would be a polite way to get your answer.

            Also, if people cared so much about “single, statically linked, standalone executables” I would not have neither Python nor Perl installed on my system, and on the systems I’m connecting to over SSH. Or any other “dynamically linked” utilities, including SSH.

            1. 3

              Also, if people cared so much about “single, statically linked, standalone executables” I would not have neither Python nor Perl installed on my system, and on the systems I’m connecting to over SSH.

              I think the requirement to have a bajillion Python or Ruby libraries installed is why people have started to care about this sort of thing. In my experience, Go has been adopted for CLI tools partly as a rejection of this pattern since the Go compiler generates statically linked binaries (the fact that it handles cross-compilation fairly well is another benefit).

              1. 1

                Yes, “small python scripts” are basically useless if they require anything not in the stdlib, because then they’re not small anymore if you need dependencies (in this particular scenario) and that’s why most people still use shell scripts, or Go for statically compiled binaries.

          2. 2

            Sorry for going off topic, but if you want something else like the mentioned batchcolor, I’ve found that lnav is good enough for my (non sysadmin-) needs.

            1. 1

              There are people who solve a problem elegantly and there are people who have a ~/bin with 50 tools in 5 languages (30 of them in bash, ofc).

              Really nice article.