56 ms·

I would like completion to automatically work on aliases in bash. I use bash over zsh in order to become better at bash programming, but completion of aliases i

I would like completion to automatically work on aliases in bash. I use bash over zsh in order to become better at bash programming, but completion of aliases is the main thing that makes me miss zsh. Well that and * * globbing syntax. (How do I cause two consecutive asterisks to be rendered as such in HN?)

hibbelig 8y ago
Bash version 4 supports * *.
- Myrmornis 8y ago
  Thanks, updated.
kstrauser 8y ago
> I use bash over zsh in order to become better at bash programming That's masochism. It's perfectly reasonable to use different interactive and programming shells. I mean, I write most of my would-be shell scripts in Python these days, but I wouldn't want to use it as my main command line (although xonsh is actually quite nice).
- Myrmornis 8y ago
  It's perfectly reasonable, but what's relevant is whether it's optimal. In today's world, with the ascendancy of cloud services and containerization, shell scripting continues to be just as important a skill for software engineers as it was in 2008, 1998, or 1988. And today, the language of production shell scripting is bash. Therefore, using bash in one's personal system is good training for the skills you will make use of in production systems. E.g. see https://google.github.io/styleguide/shell.xml https://google.github.io/styleguide/shell.xml > bash is the only shell scripting language permitted for executables. I'm surprised you choose to write would-be shell scripts in python. I think that a major reason that shell scripting endures is that handling process management and process output is much more work in real programming languages than in dedicated shell languages. EDIT: But thanks for the pointer to xonsh; that looks fun. Something innovative like that could definitely tip the balance in favor of using that for local shell work and leaving bash as a language one has to know for production work.
  - kstrauser 8y ago
    I write plenty of shell scripts where appropriate, but my main point was really that you don't need to couple your interactive environment to your scripting environment. Sure, write your shell scripts in bash. That doesn't mean you need to use that as your regular shell, though.
    - Myrmornis 8y ago
      It's true. My thinking was that there are some techniques that I use in both interactive shell usage and in scripts, and that using the same language for both would teach me them better. I'm trying to think what the best examples are, having run this experiment on myself for a couple of years now. I think one is process substitution with <() and io redirection stuff like <<<. Also IIRC correctly bash and zsh differ in whether piped commands run in different subshells. Stuff like that; I'd like to just have firmly in my mind for interactive shell and scripting and not have to know two similar languages. But I miss tab completion for aliases.

hibbelig 8y ago

Bash version 4 supports * *.

Myrmornis 8y ago
Thanks, updated.

kstrauser 8y ago

> I use bash over zsh in order to become better at bash programming That's masochism. It's perfectly reasonable to use different interactive and programming shells. I mean, I write most of my would-be shell scripts in Python these days, but I wouldn't want to use it as my main command line (although xonsh is actually quite nice).

Myrmornis 8y ago
It's perfectly reasonable, but what's relevant is whether it's optimal. In today's world, with the ascendancy of cloud services and containerization, shell scripting continues to be just as important a skill for software engineers as it was in 2008, 1998, or 1988. And today, the language of production shell scripting is bash. Therefore, using bash in one's personal system is good training for the skills you will make use of in production systems. E.g. see https://google.github.io/styleguide/shell.xml https://google.github.io/styleguide/shell.xml > bash is the only shell scripting language permitted for executables. I'm surprised you choose to write would-be shell scripts in python. I think that a major reason that shell scripting endures is that handling process management and process output is much more work in real programming languages than in dedicated shell languages. EDIT: But thanks for the pointer to xonsh; that looks fun. Something innovative like that could definitely tip the balance in favor of using that for local shell work and leaving bash as a language one has to know for production work.
- kstrauser 8y ago
  I write plenty of shell scripts where appropriate, but my main point was really that you don't need to couple your interactive environment to your scripting environment. Sure, write your shell scripts in bash. That doesn't mean you need to use that as your regular shell, though.
  - Myrmornis 8y ago
    It's true. My thinking was that there are some techniques that I use in both interactive shell usage and in scripts, and that using the same language for both would teach me them better. I'm trying to think what the best examples are, having run this experiment on myself for a couple of years now. I think one is process substitution with <() and io redirection stuff like <<<. Also IIRC correctly bash and zsh differ in whether piped commands run in different subshells. Stuff like that; I'd like to just have firmly in my mind for interactive shell and scripting and not have to know two similar languages. But I miss tab completion for aliases.