[HN Gopher] Start all of your commands with a comma (2009)
___________________________________________________________________
Start all of your commands with a comma (2009)
Author : vmbrasseur
Score : 275 points
Date : 2024-06-23 18:12 UTC (4 hours ago)
(HTM) web link (rhodesmill.org)
(TXT) w3m dump (rhodesmill.org)
| Brajeshwar wrote:
| This works for text-expansion snippets too. All of the text
| expansions that I do with Alfred (other tools might work, too)
| are all comma phrases. I realize that writing English or even
| programming scripts/tag, I'd never (not so far) encounter a word
| or text that starts with a comma immediately followed by
| anything. I used to use period but have stumbled on instances
| such as file extension where a period can be followed by words.
| abdusco wrote:
| > I'd never (not so far) encounter a word or text that starts
| with a comma immediately followed by anything.
|
| Agreed. I prefer using `!bang`s for the same reason for
| expanding text.
| codetrotter wrote:
| 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 that collided with
| one of my own tools, I'd probably sooner alias that other tool to
| a new name that didn't collide with mine, than to change any of
| my own tool names.
|
| It's just too comfortable to use these two-character tools of
| mine.
| oguz-ismail wrote:
| This. 1-3 character names should be reserved for user
| aliases/functions/scripts and standard utilities.
| jmclnx wrote:
| All my personal commands begin with 'j'. Got real fun when java
| came around. Using commas is a rather interesting idea.
|
| But at least I did not start them with a 'k' (KDE) :)
| setopt wrote:
| I tend to make all my git aliases into two-letter combos
| starting with g. So `gs` is `git status`, for example. Once in
| a while I actually really need GhostScript though, it's
| brilliant for e.g. embedding fonts into PDF files. Usually I
| then go with `env gs`.
| mozman wrote:
| 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?
| L8D wrote:
| I think the hip thing to do is just use your spare time to
| build stuff, and organically learn from building stuff. Self-
| sufficiency, creativity and generally being a self-starter is
| what's hip. More time spent building translates into an
| incentive to pickup tricks and relying on yourself to find hip
| solutions to actual problems.
| d0gsg0w00f wrote:
| Also in "management", also feel like my skills will atrophy if
| I don't keep up.
|
| What I do is make tools to make my life easier. For example, if
| there's a web service at work I use for mundane lookups I'll
| find out if it has an API and write a CLI for it to speed up my
| daily grind. Once it's tuned to my liking I'll share it with
| the team. I do struggle to convince others to try it. Not sure
| why. But I don't really care because I use the tools every day.
| james_marks wrote:
| 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.
| bityard wrote:
| Good idea overall, I must say.
|
| It's one more key press, but I'm pretty sure I would use
| underscore for the first character.
| kraktoos wrote:
| Never thought about that, cool!
| genericacct wrote:
| best idea i've read in a while, will do
| tedunangst wrote:
| Funny. My ~/bin is filled with commands that I want to override
| the system version.
| mozman wrote:
| Wrappers or replacements? If it's a wrapper do you remove local
| bin from path or hard code system path?
| tedunangst wrote:
| Yeah, shell script that runs /usr/bin/x or whatever.
| bqmjjx0kac wrote:
| > 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`.
| mozman wrote:
| But then you start using some tool that expects $0 in the
| system path and breaks causing frustration and debugging.
|
| Pick your poison
| bqmjjx0kac wrote:
| Fair point. I've been doing this for years and none of my
| scripts have ever caused any (noticeable) breakage, though.
|
| The danger is also mitigated because I only modify my own
| user's shell rc file. Any daemons running as root or their
| own user are unaffected.
| mekoka wrote:
| Article is from 2009. Plenty of prevalent short named tools
| have been released since then, causing exactly this sort of
| issues. Just thinking about it, "node" and "npm" come to
| mind.
| dsp_person wrote:
| One of the benefits is using fzf autocomplete. E.g. in fish
| type the first char of the command and Tab to launch fzf. Then
| `,`+Tab is a quick way to filter these custom commands. Versus
| `ls ~/bin` would be a lot of characters for something I do a
| lot, or maybe I'd be going `ls`+UpArrow+UpArrow+UpArrow to
| autocomplete that first.
| mixmastamyk wrote:
| The "ls " part is not necessary for tab completion.
| ~/bin<tab><tab>
|
| Is enough. Not that short, but is something done infrequently
| in my experience. Maybe I'd do it more if it was easier?
| malux85 wrote:
| ls ~/bin is wayyyyy slower to type than ,<tab>
| sre2 wrote:
| I've been doing this for at least a decade. Was introduced to the
| idea by a colleague who might have read this blog post.
|
| I usually do the same with commands where you are able to create
| sub-commands too, like git-,home (which allows you to run `git
| ,home add -p` and it conveniently set GIT_DIR to something and
| GIT_WORKTREE to $HOME). Sadly you can't do it with git aliases, I
| have to live with them starting with a dot (via '[alias ""]' as a
| section).
| thanatos519 wrote:
| Encountering this idea 5 years allowed me to bring order to my
| bag of shell tricks! I have over 50 ,commands between aliases and
| ~/bin and my shell life is way smoother than the previous
| agglomeration.
| rahimnathwani wrote:
| I'm curious how folks manage their important local
| configurations, e.g.
|
| - is your ~/bin directory a git repo?
|
| - if you git to manage your dot files, do you use hard links or
| soft links?
| mr_mitm wrote:
| I use ansible
| nucleardog wrote:
| There are tools to manage it for you that I'm sure someone will
| come along and mention, but I've got a repo I check out at
| `~/.home`, then a shell script they just symlinks everything
| into place.
|
| So .bashrc is a symlink to ~/.home/.bashrc, ~/.config/nvim to
| ~/.home/.config/nvim, etc.
|
| It's simple and only relies on having something sh-compatible
| available so portable now and in the future.
|
| To manage per-system tweaks, I have places that include an
| additional file based on hostname. For example my .bashrc has
| something like: if [ -f
| "$HOME/.bashrc.$HOSTNAME" ]; then source
| "$HOME/.bashrc.$HOSTNAME" if
|
| Which will include a bashrc file specific to that host if it
| exists.
|
| Been working well for me for... a decade now?
| asix66 wrote:
| Re your second question, here's how I manage my dotfiles:
|
| https://github.com/andersix/dotfiles
| codetrotter wrote:
| I have some essential stuff for zsh config in a git repo.
|
| For my most important custom bins, they are written in Rust and
| published to crates.io so I cargo install them from there. It's
| just one crate, with wrappers for the git commands that I use
| day to day
|
| In addition to this, I have host specific repos with some
| scripts. These scripts are not in my path but are instead
| scripts that run on a schedule from cron. These scripts run and
| log various facts about the machine such as zpool status and
| list installed packages, and auto-commit and push those to
| their repo. And the other kind of script I have invokes zfs
| send and recv to have automatic backups of data that I care
| about.
|
| In addition to this I have a couple other git repos for stuff
| that matters to me, which either runs via cron (retrieving data
| from 3rd parties on a schedule) or manually (processing some
| data).
|
| For neovim I stopped caring about having a custom RC file at
| all. I just use vanilla neovim now on my servers. On my laptop
| I use full blown IDEs from JetBrains for doing work.
| lucideer wrote:
| I use chezmoi - it handles both elegantly & has no real
| requirements w.r.t. how you choose to structure your
| filesystem. It also handles recovery well when you mess things
| up.
| aslatter wrote:
| I didn't invent this, but I have a headless "config" checkout,
| and have a git-alias which sets my home-directory as the work-
| tree: git init --bare $HOME/.config/repo
| alias config='/usr/bin/git --git-dir=$HOME/.config/repo --work-
| tree=$HOME' config config --local
| status.showUntrackedFiles no
|
| Then I can do things like "config add", "config commit", and
| "config push".
| dsp_person wrote:
| My ~/scripts is a git repo
|
| My dotfiles/configs are a mix of the following setup on boot:
|
| - one-way copy of config file from $repo/$path to $path
| (prevents apps from modifying my curated config or adding
| noise)
|
| - or make it a symlink (if I want it mutable)
|
| - or make it a bind mount (if a symlink won't work; can be a
| file or folder)
|
| - or make it a one way copy but add a file watcher to copy
| changes back to the repo (if none of the above work. Some
| programs fail if the file they need is a symlink or is bind
| mounted)
|
| For dotfiles using a one-way copy, whenever I change a setting
| I want to persist I have to manually copy or edit the original
| $repo/$path. I can take a diff against the repo for a hint, or
| use `inotifywait -r -e modify,create,delete,move . ~/.local
| ~/.config -m` for something new.
|
| Not using hard links since the dotfiles are likely to be on a
| different filesystem (or dataset) than their target paths.
| oalders wrote:
| I keep everything I care about in a dot-files repo that knows
| what to install where in different places. I wrote a little
| tool to make it easier for me to do this:
| https://github.com/oalders/is
| kataklasm wrote:
| Look into gnu stash
| interroboink wrote:
| I have a custom tool built up over the years that keeps the
| history of that stuff in repos, but the actual files in ~/bin
| are usually hadlinks to the repo files (configurable - can be
| softlink or copy, too).
|
| Every few weeks or months, I run a command on each system that
| gathers up any accumulated changes I've made to these files and
| syncs them to common machine that has all the repos. I merge
| those changes, then run another command to install the updates
| on all machines, so everything stays in-sync, over time.
|
| I found that these ~/bin scripts and config files fell into a
| bit of a "donut hole" of development effort, where it was too
| much bother to maintain a full repo/build/install setup for
| every single script independently, but I _did_ want to keep
| changes in sync and track them over time, rather than just
| having each system diverge forever.
|
| So, my solution was to bundle lots of scripts together, into
| just a few repos, and sync/merge/etc them in bulk, to
| streamline the process.
|
| A downside is lots of my commit notes are just a generic
| "gathering up latest changes" since I'm slurping up lots of
| edits to unrelated files at once. Hasn't really been a problem
| for me, though. I mostly just care about having the history.
| sandreas wrote:
| I use a git repository `dotfiles` containing several configs in
| `dotfiles/etc/`.
|
| Since I use `zsh`, I usually only symlink the
| `dotfiles/etc/zsh/.zshrc` to `$HOME/.zshrc`, while the `.zshrc`
| loads environment variables settings all required paths for my
| tools, e.g.: export
| PATH="$HOME/bin:$HOME/dotfiles/scripts:$PATH" export
| STARSHIP_CONFIG="$HOME/dotfiles/etc/starship/starship.toml"
| export GIT_CONFIG_GLOBAL="$HOME/dotfiles/etc/git/.gitconfig"
| export MYVIMRC="$HOME/dotfiles/etc/vim/vimrc" export
| VIMINIT='source $MYVIMRC' # ...
|
| The only files of `dotfiles` I copy over are for ssh, because
| ssh checks file permissions for security reasons and does not
| allow symlinks.
| RulerOf wrote:
| Symbolic links set up with dotbot[1].
|
| Since the link directives are idempotent, you can run it on
| every login shell if you desire. I ended up setting up a shared
| jumpbox used by some contractors with it so they could work
| with our internal tooling without requiring excessive setup,
| and wrapped it into a shell startup script[2] and found it
| performant enough that I couldn't tell the difference.
|
| 1: https://github.com/anishathalye/dotbot
|
| 2:
| https://gist.github.com/RulerOf/f41259f493b965c9354c2564d85b...
| zirkuswurstikus wrote:
| Moin, To manage my dotfiles I use git and an alias. See
| https://www.atlassian.com/git/tutorials/dotfiles
| tschumacher wrote:
| I got this from an old HN comment I can't find anymore. I have
| this in my .bashrc: alias dotfiles='git --git-
| dir=$HOME/.dotfiles --work-tree=$HOME'
|
| And I init my dotfiles into a fresh home directory like this:
| git clone --bare gitolite3@example.com:dotfiles $HOME/.dotfiles
| git --git-dir=$HOME/.dotfiles --work-tree=$HOME config
| status.showUntrackedFiles no git --git-
| dir=$HOME/.dotfiles --work-tree=$HOME reset --hard
| thefifthsetpin wrote:
| My ~/bin directory is not directly version controlled. It
| primarily consists of symlinks, often stripping file extensions
| from shell scripts (e.g., ~/bin/foobar links to
| ~/src/foobar.sh) I have just enough python scripts and go
| binaries to make me think it's worth separating src and bin.
|
| ~/src is a git repo. One script evolved into its own project
| and became a submodule within ~/src.
|
| For configuration files like ~/.foobar_rc and directories such
| as ~/.vim/, they again are not directly version controlled but
| are symlinked into ~/etc which is. I don't see any reason that
| ~/.foobar_rc couldn't be a hardlink, but it's not in my setup.
|
| I used to maintain a single repository at ~ that included ~/src
| and ~/etc as submodules, with a build script for setting up
| links. Always being within a git repository became cumbersome,
| so I moved the build tools into their respective directories
| (~/src and ~/etc) and now clone and build each repository
| manually.
|
| Lastly, since private repos aren't (weren't?) free, those
| submodule repos are really just branches of the same repo that
| share no common ancestors.
| wruza wrote:
| My main system is windows, so it's c:/CmdTools repo in PATH. I
| tried to learn `stow`-likes, but it's not worth it. I just
| clone/pull/push it in that fixed location. Mostly cmdbash
| scripts.
|
| More complex (multi-file) tools are usually separate ts or
| python projects. Node has {npm,yarn} link, which puts a starter
| .cmd somewhere in PATH, out of box. Python scripts I usually
| run through .cmd "alias" files in c:/CmdTools, there's no `pip
| link` afaik.
|
| I always have MSYS2 installed and here's my cmdbash prolog:
| some.cmd: :<<BATCH @xbash %~dpf0 %*
| @exit /b BATCH for i in {1..5}; do
| echo "Hello from bash!" done
|
| xbash.exe is just msys's bash.exe that I copied to avoid
| collisions with WSL (which is a useless PR nonsense). Same with
| xgrep, xfind, xecho, xmkdir, xsort.
|
| This setup carried me for years and turns out to be a very
| reasonable windows/unix integration. I like unix architecture,
| but can't stand linux desktop. This year I've got a project
| related to linux desktop, and I'm literally become so stressed
| using it sometimes that I have to take a break or vent loudly.
| thrdbndndn wrote:
| 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 I never get it
| to work similarly here.
|
| 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. Sure, you can chmod +x to the
| script, but then you have to add a shebang line directly to the
| script itself, which I always feel uncomfortable since it's hard-
| coded (what if in future I don't want to execute my .py script
| with `/usr/bin/python` but `/usr/bin/nohtyp`?).
|
| Furthermore, I failed to find _any_ way to omit `.py` part when
| calling my script.
|
| Again, none of the above is to question the design of the Linux
| -- I know it comes with lots of advantages.
|
| But I really, really just want to run `hello` to call a
| `hello.py` script that is in my $PATH.
| compootr wrote:
| can't you use a shebang in Linux with .py files? And, as for
| removing .py, just remove the extension and make it executable
| or use a symlink
|
| from a google search, https://stackoverflow.com/a/19305076
|
| I'm not at the computer now to test though
| LeoPanthera wrote:
| Simply remove the .py from the filename. It's perfectly
| acceptable to call it "hello".
|
| I can't think of a downside to the shebang. If you really
| wanted to run the script with a different interpreter, just
| specify it. "nohtyp hello" or whatever.
|
| If that still bothers you too much, you could define an alias
| in your shell startup. For example, in bash, you might do:
|
| alias hello="python3 /path/to/hello.py"
|
| If you were so inspired, you could even write a short script to
| automatically create such aliases for the contents of a
| directory you specify.
| heisenbit wrote:
| Node seems to be partial to whether one has a .mjs or not on
| the filename.
| djbusby wrote:
| You can use the /usr/bin/env python shebang line to work across
| python location
|
| I keep all my scripts in ~/git/$Project and symlink them into
| ~/bin and I've added ~/bin to the end of my path.
| rascul wrote:
| > 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. Sure, you can chmod
| +x to the script, but then you have to add a shebang line
| directly to the script itself, which I always feel
| uncomfortable since it's hard-coded (what if in future I don't
| want to execute my .py script with `/usr/bin/python` but
| `/usr/bin/nohtyp`?).
|
| Might be you could use binfmt_misc for that.
|
| https://www.kernel.org/doc/html/latest/admin-guide/binfmt-mi...
| MarkSweep wrote:
| Here is an article about using binfmt_misc to make .go files
| executable. I assume something similar could be done for
| python:
|
| https://blog.cloudflare.com/using-go-as-a-scripting-
| language...
| o11c wrote:
| binfmt_misc is only useful for when a fileformat does not
| allow shebangs
| rascul wrote:
| Or if you don't want to use shebangs as mentioned.
| slowmovintarget wrote:
| Linux can do this. There are probably more ways, but this is
| off the top of my head.
|
| Use an _alias_ which you set up in your initialization scripts.
| You alias "hello" to "python3 /yada/yada/hello.py" which is
| essentially what Windows is doing for you behind the scenes.
| Dove wrote:
| You could even write a script to traverse all the files in
| your bin directory and make all the aliases.
| jack_pp wrote:
| > what if in future I don't want to execute my .py script with
| `/usr/bin/python` but `/usr/bin/nohtyp
|
| you're thinking too much, people have had that shebang for 20
| years without any problems
|
| > But I really, really just want to run `hello` to call a
| `hello.py` script that is in my $PATH.
|
| I don't really understand why you're so adamant about this,
| either make a python "hello" script with a shebang or just tab
| complete hell<tab> which you should do with most commands
| anyway so the .py doesn't matter
|
| another option would be to alias but you'd have to do that
| manually for every frequent script you need
| thrdbndndn wrote:
| Tab complete does not work if the script isn't at CWD, which
| is the case here since all my script is at ~/bin/.
| rascul wrote:
| Tab complete should still work if ~/bin is in $PATH.
| kibwen wrote:
| _> then you have to add a shebang line directly to the script
| itself, which I always feel uncomfortable since it 's hard-
| coded (what if in future I don't want to execute my .py script
| with `/usr/bin/python` but `/usr/bin/nohtyp`?)_
|
| _> But I really, really just want to run `hello` to call a
| `hello.py` script that is in my $PATH._
|
| On Linux I'd say the shebang is still the right tool for this.
| If you want a lightweight approach, just have a `my_python`
| symlink in your path, then your shebang can be `/usr/bin/env
| my_python` (or heck just `/foo/bar/baz/my_python`, /usr/bin/env
| is already an abstraction).
|
| If you want a more principled approach, look at the `update-
| alternatives` tool, which provides this sort of abstraction in
| a more general way: https://linuxconfig.org/how-to-set-default-
| programs-using-up...
| ffsm8 wrote:
| > /usr/bin/env is already an abstraction).
|
| Isn't that path and the behavior of the binary defined by
| POSIX though? I thought it's as stable as you can get.
|
| That's why it's usually recommended that you use /use/bin/env
| bash vs /bin/bash in the shebang, as the latter _isn 't_
| defined by POSIX
| kibwen wrote:
| Yes, env is an abstraction for the sake of portability, but
| if you're setting up custom indirections then portability
| probably isn't much of a concern.
| cfiggers wrote:
| 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!
| cgriswald wrote:
| You can run /usr/bin/nohtyp hello.py even on a script with a
| shebang specifying a different executable.
|
| To remove the .py just rename the file to "hello", or keep
| "hello.py" and create a symlink or a shell alias called "hello"
| that points to it.
| lucideer wrote:
| > _I always feel uncomfortable since it 's hard-code_
|
| I used to think this as well, but I've since come around to the
| opposite view. Having it as a "requirement" for what's likely
| the most popular cli execution strategy enforces a (somewhat
| disorganised but still useful) defacto standard across all
| scripts. I can open up any repo/gist/pastebin in the world &
| chances are if it's intended to be run, it'll contain this
| handy little statement of intent on the first line. I might not
| actually run (env-dependent) but I'm sure I can make it.
|
| On the env-sensitivity though, if e.g. you're running nohtyp,
| as another commenter mentioned, /usr/bin/env has that covered.
| tomsmeding wrote:
| The normal way here is to name your script simply `hello`,
| start it with a shebang reading `#!/usr/bin/env python3`, and
| mark it executable. This of course makes running it as `hello`
| work (if you put it in PATH), but also:
|
| - The shebang is only specially interpreted by the Linux
| loader, i.e. when executing the file directly.
|
| - You can still run it with any other interpreter in the
| standard way: `nohtyp ~/bin/hello`. Python comments start with
| `#`, so the shebang does nothing with programs expecting Python
| code.
|
| - This situation (a script without an extension) is common on
| Linux, so Linux-aware editors understand the shebang to
| indicate a file type. At least, vim understands this and
| automatically detects a python file type without the .py
| extension.
|
| I get your wish of Windows-like behaviour, and even if you
| might be able to conspire to have Linux behave the way you
| want, it's certainly not how people _expect_ it to work, so
| prefer the above scheme for any software you send to others. :)
| Someone wrote:
| > but then you have to add a shebang line directly to the
| script itself, which I always feel uncomfortable since it's
| hard-coded
|
| It won't directly help reach your goal, but it is semi hard-
| coded. The 'correct' (but see
| https://unix.stackexchange.com/a/29620 for some caveats) way to
| write a shebang line is #!/usr/bin/env python
|
| That will make it run the first _python_ in your path.
|
| > what if in future I don't want to execute my .py script with
| `/usr/bin/python` but `/usr/bin/nohtyp`?).
|
| You could create a symlink called _python_ to _/
| usr/bin/nohtyp_ on your system in a directory that's searched
| before _/ usr/bin_ (e.g. by adding _~ /myCommandPreferences_ to
| the front of your _PATH_ )
| erik_seaberg wrote:
| To be excruciatingly correct, we should specify python2 or
| python3, because they can't interop and probably never will.
| skeledrew wrote:
| I think at this point we can rest easy that python2 has
| finally been fully purged from default installs. Heck a few
| weeks ago I installed Kubuntu 24.04 base and there was no
| Python at all...
| erik_seaberg wrote:
| Debian stable doesn't have "python" anywhere on my PATH,
| for a good reason IMHO. Shebangs say "/usr/bin/env
| python3" or hardcode "/usr/bin/python3".
| o11c wrote:
| Others have already mentioned _how_ to fix your problem, but I
| just want to mention one thing about _why_ :
|
| On Linux (really, all platforms other than Windows), file
| extensions are much less of a thing; executables of any kind
| have no extension just the +x flag (among other things, this
| means you can rewrite them in another language without breaking
| anything).
|
| The .py extension is only relevant for modules meant to be
| _imported_ ; for scripts being run, if you really need to know,
| you are supposed to look at the shebang (usually #!/usr/bin/env
| python for externally-distributed scripts; this gets
| overwritten to #!/usr/bin/python or whatever for scripts
| packaged by the distro itself).
|
| Note also that, while shebangs don't support multiple
| arguments, the GNU version of `env` supports a `-S` argument
| that can emulate them (the argument length problem remains
| though).
| chrisfinazzo wrote:
| _File name extensions_.[1]
|
| I'm not saying you're wrong, but let's be clear about what
| these are. I would point out that Linux inherited some, but
| not all of its naming conventions from Unix (as did macOS),
| but at least here, that is a secondary concern.
|
| Carry on...
|
| [1]: https://arstechnica.com/gadgets/2001/08/metadata/
| harrisi wrote:
| You can utilize `command_not_found_handle()` for the extension-
| less behavior.
| BiteCode_dev wrote:
| You don't need the file to be named "hello.py". You can name it
| just "hello", with the right shebang it will work fine.
| meken wrote:
| Your example got me thinking about the difference between how
| the windows shell and Unix shell is designed. Seems like the
| windows shell knows about extensions, whereas the Unix shell
| does not
|
| That's an interesting feature for a shell to have. Thanks!
| MadnessASAP wrote:
| 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 handle it appropriately.
|
| I personally am a fan of the Unix way but I can see why some
| might prefer the DOS convention.
| D-Coder wrote:
| Speaking of heritage... 8+3 goes back at least to
| DECSystem-10 on PDP-10s.
| vincent-manis wrote:
| 6+3 on DEC TOPS-10.
| MadnessASAP wrote:
| _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.
| moritzwarhier wrote:
| > 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 a file extension of
| sorts.
|
| If chmod +x ./malware.py ./malware.py
|
| does not work, check the path the Shebang points to.
|
| That being said, as long as an interpreter can execute the
| scripts as regular argument, you should be able to get this
| behavior also for xdg-open: xdg-open malware.py
|
| if you really want to do that by default.
|
| This should be equivalent to double-clicking file in the
| default file manager, IIRC (am on Mac now).
|
| I had an alias "xop <file>" when using Linux as my primary
| desktop OS.
|
| But I only used this for data files (images, documents etc)
| where the default already works.
|
| Wouldn't recommend setting an interpreter as default for
| executable scripts.
|
| You might want to not execute scripts by default, instead
| opening them in an editor for example.
|
| xdg-open is a Gnome thing I think, but that doesn't mean it's
| unavailable for other desktops. I know it from Xubuntu (so
| Xfce).
|
| So I'd really advise against that, But if you want to execute
| all python files by default in any GUI context, too you could
| set this kind of default there
|
| 'man xdg-open' might help, or maybe you could even select a
| specific Python executable as the default for .py files after
| double-clicking in the File Manager.
|
| Again, bad advice
| jraph wrote:
| > you have to add a shebang line directly to the script itself,
| which I always feel uncomfortable since it's hard-coded (what
| if in future I don't want to execute my .py script with
| `/usr/bin/python` but `/usr/bin/nohtyp`?).
|
| I believe the elegant solution to this is update-alternatives,
| which lets you tell the system which actual program to call.
| Maybe look into update-alternatives, I haven't looked into this
| much but it seems like it might interest you particularly.
| That's the closest equivalent to file association for the UNIX
| shell I would guess.
|
| You could also have a specific folder that you control in your
| PATH that symlinks to the Python you want to use.
|
| This handles the default, but you can still call your script
| with the program you want if you ever wish to bypass that.
| helpfulContrib wrote:
| I dislike this immensely. It costs nothing to type "~/bin" in
| front of the command each and every time. And it means I can put
| comma's wherever I want in some commands that use them, like SQL
| ..
|
| I do, however, like to comment my custom commands:
| $ mv ~/Desktop/*pdf ~/Documents/PDF # pdfsync $ for i in
| ~/Documents/Development/JUCE/JUCE_Projects/* ; do ; cowsay $i ;
| cd $i ; git pull ; git fetch --all ; git submodule update --init
| --recursive ; done # updatejuce
|
| CTRL-R "updatejuce" or "pdfsync" .. and off we go ..
|
| A much nicer way of finding my custom commands ..
| teo_zero wrote:
| > The lower-case letters are the very characters used in system
| commands; brackets, backslashes, the colon, the back-tick, and
| the single-tick all had a special meaning to the shell
|
| Please note that brackets have no special meaning to the shell.
| 38 wrote:
| wrong
|
| https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
| adrian_b wrote:
| Brackets have a special meaning in the UNIX shell since the
| earliest times.
|
| Together with "*" and "?", the brackets "[" and "]" have been
| used by the UNIX shell since some of its earliest versions
| (already many years before the Bourne shell) in pattern
| matching for pathname expansion (globbing).
|
| For example, if you have in a directory 3 files named "file1",
| "file2" and "file3", then
|
| "ls file?" will output
|
| file1 file2 file3
|
| while "ls file[13]" will output
|
| file1 file3
| gdavisson wrote:
| Brackets are used in shell wildcard ("glob") expressions. For
| example, if you try to use "[bar]" as a command, the shell will
| first look for files named "b", "a", and "r" in the current
| directory, and if it finds any it'll use the first one as the
| command name and any others as arguments to it.
|
| But as far as I can see, using a close-bracket as the first
| character in a command is safe, since it cannot be treated as
| part of such a pattern. Open-bracket (without a matching close-
| bracket) would work in many shells, but will get you a "bad
| pattern" error in zsh.
| jwilk wrote:
| Discussed in 2020:
|
| https://news.ycombinator.com/item?id=22778988 (90 comments)
| dang wrote:
| Thanks!
|
| , macroexpand:
|
| _Start all of your commands with a comma (2009)_ -
| https://news.ycombinator.com/item?id=31846902 - June 2022 (121
| comments)
|
| _Start all of your commands with a comma (2009)_ -
| https://news.ycombinator.com/item?id=22778988 - April 2020 (89
| comments)
| declan_roberts wrote:
| I like it I think. I'd probably be more inclined to add the comma
| to the end, that way tabbing on "mount" would bring up "mount and
| mount," which is your personal one.
| c22 wrote:
| I guess this works great right up to when the contents of _~
| /bin/_ are added to a CSV for whatever reason.
| mixmastamyk wrote:
| Use TSV instead.
| tgv wrote:
| So much better. And you don't have the ridiculous
| "localization" of csv: over here, the field separator
| defaults to a semicolon. I suppose someone thought it was so
| terribly important to have a decimal comma in a csv file that
| any form of common sense went out of the window.
| g15jv2dp wrote:
| Doesn't work with powershell (which, to be fair, was quite new at
| the time this blog post was released).
|
| But honestly, while 2 or 3-letters aliases are tricky, I've very
| rarely had issues with 4-letter aliases. There are 456k
| possibilities. On my small opensuse install, my PATH contains
| only 105 4-letter executables.
| TrianguloY wrote:
| Those can really be called comma_nds!
|
| Ahem. Nice idea though, I think I'll start using it...
| RandomGuy45678 wrote:
| Love it!
| zuminator wrote:
| Surely ,nds?
| zogrodea wrote:
| I think "comma_nds" ("commands" if you remove the underscore)
| makes the pun mkre obvious.
|
| I didn't get it at first thought, thinking of the .nds file
| extension for Nintendo DS ROMs.
| morningsam wrote:
| An alternative method for avoiding collisions in PATH is to use
| really long executable names that are unlikely to be used by
| other executables and then have shorter aliases for them in your
| bashrc. The aliases won't affect executables called from within
| scripts and you can still refer to your executables by their long
| names in your own scripts.
|
| One drawback is that this doesn't have the same tab completion
| ergonomics, which I have to admit is really nifty.
|
| EDIT: And another is that collisions can still occur in scripts
| that need to be sourced rather than executed as a sub-process
| (like Python's venv activation scripts). But those are rare.
| olejorgenb wrote:
| > One drawback is that this doesn't have the same tab
| completion ergonomics, which I have to admit is really nifty.
|
| They do in zsh
| sctb wrote:
| Similarly, some Lisps (like Scheme48 IIRC) use a comma to begin
| REPL commands (as distinct from Lisp forms) because commas
| outside of quasiquotation forms are otherwise syntax errors.
| lloydde wrote:
| Starting with comma is also a common technique in the text
| expander / text replacement community.
| klysm wrote:
| things like this happen all the time when we didn't implement
| name spacing when we should have
| tanelpoder wrote:
| Great idea! And if for some reason you feel like your filenames
| should stay as they are (without a comma), you could just add
| symlinks to all executable files in your bin directory:
| $ cd ~/bin $ for x in $(find . -type f -perm /a=x -exec
| basename {} \;) ; do echo $x ; done temps $ for
| x in $(find . -type f -perm /a=x -exec basename {} \;) ; do ln -s
| $x ,$x ; done $ ls -l total 4 lrwxrwxrwx 1
| tanel tanel 5 Jun 23 16:38 ,temps -> temps -rwxr--r-- 1
| tanel tanel 251 May 30 23:26 temps
| metadat wrote:
| Discussed previously:
|
| https://news.ycombinator.com/item?id=22778988 (April 2020, 90
| comments)
| dotancohen wrote:
| I was recently poking around ~/.local/bin/ when I noticed that it
| had dozens of executables that I don't remember putting there.
| Mostly pyside things, but some other scripts as well. I really
| had to open each to jog my memory, especially about which scripts
| I had written myself and which were by other people.
|
| The idea about starting my own scripts' names with a comma would
| have made the job go much faster, and I'm sure would have helped
| to job some memories about why each script was written, before
| opening it.
| o11c wrote:
| Normally ~/.local/bin/ is only for installed scripts; locally-
| written ones go in ~/bin/
___________________________________________________________________
(page generated 2024-06-23 23:00 UTC)