When I read the headline I thought this was going to be a terrible idea but I quite like it, especially the bit about using tab to list all your tooling. Anecdotally I haven’t had many namespaces collisions recently. I’ve also let myself go a bit after going into management. My tech skills are 10 years too old. Any tips from someone else on where they started to be hip again?
I built my side project in a separate, trendier stack than the one I’m comfortable with at work for this very reason.
Just to see some new perspectives and be conversant in the trends.
Some of the new stack now crosses over to work, and I have a deeper appreciation for some of the older pieces.
It's can be traced back to the roots of each OS. Windows has it's heritage in the land of DOS where files had an 8 character name with a 3 character extension and that extension carried meaning for the OS. Linux being of Unix ancestry which had no such concept as a file extension. It was the responsibility of the application or kernel to discern what type a file was. Typically by the first few bytes of a file and han…
Speaking of heritage... 8+3 goes back at least to DECSystem-10 on PDP-10s.
Everything goes back to the PDP-10 we are all using the incestuous off-spring of DEC.
Whether that is good or bad is left as an exercise to the reader.
A kinda relevant question. I use Windows most of time. Like the author, I have bunch of CLI scripts (in Python mainly) which I put into my ~/bin/ equivalent. After setting python.exe as the default program for `.py` extension, and adding `.py` to `%pathext%`, I can now run my ~/bin/hello.py script at any path by just type `hello`, which I use hundreds of time a day. I now use Linux more and more (still a newbie) but…
> Firstly, Linux seems to have no concept of "associated program", so you can never "just" call .py file, and let the shell to know to use python to execute it. There is, but not in the shell syntax. It's an application concern normally delegated to the desktop/GUI. For shell scripts, the executable is usually declared in the script itself, by adding a Shebang and making the file executable. Think of the Shebang like…
On Ubuntu and probably Debian, the 'mailcap' package is (I think) installed by default. It provides the 'see', 'view', 'edit', 'print' and 'compose' commands which open a file in a suitable default program.
I use short custom command names like aa, st, di, dp, cm and le in some thin wrappers around git. One of these names actually collides with a utility that is installed by default on some systems. Doesn’t matter to me. I have my own bin dirs before the system dirs in my path, so mine “win”, and I’m not really interested at all in the tool that mine has a name collision with. If someone were to make a useful to me tool…
This approach can lead to issues like `apt-get upgrade` launching dwarf fortress:
A kinda relevant question. I use Windows most of time. Like the author, I have bunch of CLI scripts (in Python mainly) which I put into my ~/bin/ equivalent. After setting python.exe as the default program for `.py` extension, and adding `.py` to `%pathext%`, I can now run my ~/bin/hello.py script at any path by just type `hello`, which I use hundreds of time a day. I now use Linux more and more (still a newbie) but…
You could have a shim script with the shebang that only exists to call the "real" script using Python. /usr/bin/hello: #!/usr/bin/bash python3 /usr/bin/hello.py /usr/bin/hello.py: print("Hello, world!") Console: $ chmod +x /usr/bin/hello $ hello Hello, World!
Why is this response being marked down? Just off the top of my head Sublime and VSCODE do this. I prefer `/usr/local/bin` since your package manager won't touch it.
> Because my shell script names tended to be short and pithy collections of lowercase characters, just like the default system commands, there was no telling when Linux would add a new command that would happen to have the same name as one of mine. Not sure I understand this problem. I just put my bin directory at the front of $PATH rather than the end. To browse my commands, I simply `ls ~/bin`.
ls ~/bin is wayyyyy slower to type than ,
You could make a command called , that runs ls ~/bin ...