Live data from Hacker News

Start all of your commands with a comma (2009)

rhodesmill.org

211–220 of 252 posts

Re: Start all of your commands with a comma (2009)

#211
post #158

Earlier quoted context omitted.

Elaborate?? "." has been at the end of my PATH for like 20 years.

Just to save the trouble of writing './'?

Yes??? :)

I'm not the crazy one here! That's a whole two characters on the same side of the keyboard...

Re: Start all of your commands with a comma (2009)

#212
post #148

Earlier quoted context omitted.

https://github.com/nix-community/comma

I'm not sure I'll ever understand why they replaced their working ~50 line shell script with a Rust program that just shells out to the same nix-* commands. I appreciate that there are some safety benefits, but that program is just not complex enough to benefit.

Maybe it was fun?

Re: Start all of your commands with a comma (2009)

#213

I use a different prefix character, e.g. "[", but I have been doing this for years I started using a prefix because I like very short script names that are easy to type I prefer giving scripts numbers instead of names Something like "[number" I use prefixes and suffixes to group related scripts together, e.g., scripts that run other scripts I have an executable directory like ~/bin but it's not called bin. It contain…

> I prefer giving scripts numbers instead of names > Something like "[number" > It contains 100s of short scripts So you call scripts like [1 [2 [3 [4 ... and remember what each one of them does? If yes - that's nuts, I'd visit a doctor.

Thank you

Re: Start all of your commands with a comma (2009)

#214

Earlier quoted context omitted.

Because it's useless extra typing. People try to narrow commands down to two fucking chars and you suggest to type the whole goddamn path!

Nobody suggested typing whole paths.

They did. Just not explicitly.

Re: Start all of your commands with a comma (2009)

#215

Earlier quoted context omitted.

Presumably a script that aliases a common thing or something and then it uses the same. E.g. someone adds ./sed that has some default params and calls sed. You’re intended to call it with ~/not-in-path/defaulted/sed and it is supposed to then call sed but instead calls itself if it’s earlier in the path hierarchy. Might even be as simple as “detect if I’m running gnu sed or bsd sed and use the appropriate one”. Obvio…

Not if if you APPEND the dot path to the PATH env: the system traverses the dirs specified in the PATH env from left to right and stops at first match. Your system's sed binary is in the dir that's to the left of your '.' dir.

Appending is much better than prefixing, but having "." in the path, anywhere, can still open you up to running mistyped commands (arguably a much less common possibility, but still a possibility).

I.e., you have "." as the very last item in your path. You are in /tmp/ (so a directory other uses can write files to). You mean to type "ls -l something" to look for "something" files. But instead, you just miss the space, and type "ls-l something*", and some other nefarious user has left a /tmp/ls-l binary behind just waiting to be run. It could package up your ~/.ssh folder and ship it off to "nefarious" user, and then do a proper "ls -l" so that you may not even notice the typo.

And, if you happen to be root when you are in /tmp and mistype ls-l, and if the ls-l binary checks to see if it is being run as root, it could then do even worse. For example, it could leave behind an suid to root bash or sh executable in 'nefarious user's' home dir, so that 'nefarious' can now become root at some point later and proceed to actually 'own' the system.

Re: Start all of your commands with a comma (2009)

#216

Earlier quoted context omitted.

Nobody suggested typing whole paths.

They did. Just not explicitly.

I've asked you why prepending paths to PATH instead of appending was a bad idea. How is having typing full paths has anything to do with it?

Re: Start all of your commands with a comma (2009)

#217
I actually have the below clashes function in my bashrc to detect overloaded names, and a few compgen aliases for sorted formatted command lists. Clashes takes a few seconds to chew through the 3000ish commands on my Steam Deck.

I also discovered the comma thing myself, and use it for `xdg-open ` aliases, i.e. `,aw xdg` searches archwiki for "xdg", since the SteamOS on this thing doesn't have manpages.

  alias words='iftty xargs'   # join by spaces
  alias c='compgen -c | sort -u | words' # eg: c | grep ^k | chop
  # ... a for aliases, f for functions etc ...
  alias man='g !archman'      # https://man.archlinux.org
  alias ,aw='g !aw'           # https://wiki.archlinux.org
  alias ,mdn='g !mdn'         # https://developer.mozilla.org
  alias ,nix='g !nixpkgs'     # https://search.nixos.org
  # ... a dozen others ...

  g() { local IFS=+; xdg-open "https://ddg.gg/?q=$*"; }
  iftty() { if [ -t 1 ]; then "$@"; else cat; fi; }

  chop() { # [TABS] [STARTCOL] [CUTOPTS..] # eg. ls ~/.co* | chop
    set -- "${1:-2}" "${2:-1}" "${@:3}"
    cut -c "$2"-$(($2+8*$1-2)) "${@:3}" | column #| less
  }

  clashes() { # [CMDS..] # print overloads eg: clashes $(c)
    (($#)) || set -- $(compgen -A alias -A function)
    local ty cmd; for cmd; do ty=($(type -at "$cmd"))
    ((${#ty[@]}>1)) && echo -n "$cmd "; done; echo
  }

Re: Start all of your commands with a comma (2009)

#220

Earlier quoted context omitted.

Nobody suggested typing whole paths.

They did. Just not explicitly.

The only situation where you'd need to type a full path is when you have a name collision. But the suggestion to not worry about collisions with unknown system binaries also said to put the script folder first. In that situation running the script doesn't need a full path, and you won't be running the unknown system binary. So you won't be typing full paths.

Please explain the non-explicit suggestion you see, because I don't see it.

It's clear that "adding your script directory in front of the PATH" means a one time edit to .bashrc or equivalent, right? In normal use you're not typing it.

Post reply on HN