Hacker News Reader

Comment by salamander014 | Hacker News Reader

xonsh is absolutely the right way to go here. There are a lot of 'gotchas' when it comes to building a shell that isn't 'just' a novelty but actually usable.

Shells are most successful when you don't need to think in order to use them. Especially since everyone that's used linux in the past 30(?!) years has the same basic foundation for how to use the command line, the best Shell will feel familiar to sh and bash, but better.

Math, logic, string and value manipulation, all those things I need to google because I don't remember whether an if statement in bash needs single [ ] or double [[ ]] or '' or "" or ; or spaces or all those weird gotchas.

I understand that many people do know how to program in bash effectively. That doesn't mean it's the future. It's like the Perl vs Python thread from the other day.

Xonsh is intuitive. Xonsh is well designed. Long live Xonsh.

View on HN

> all those things I need to google because I don't remember whether an if statement in bash needs single [ ] or double [[ ]] or '' or "" or ; or spaces or all those weird gotchas.

This made me chuckle. A few years ago, I went on a learning spree to finally memorize all of these sparse semantics so I could write bash scripts fluently. I ended up having a really good grasp, could write scripts with no flailing.

Six months later, I was back to searching "bash double quotes vs single". Unless you use them every day, for years, these semantics just fall right out of your head.

Yeah, having played with some scripting-languages-as-shells, the value that a shell adds over REPL is not insignificant... but haphazardly trying to mash together a scripting language and a shell can produce something like Powershell, which is incredibly powerful and expressive but infuriatingly inconsistent and full of gotchas.

> the value that a shell adds over REPL is not insignificant

Could you expand on this? I've been thinking about using a repl as a system shell. The piping issue is solved easily by sh.py. The main problem I can think of is startup latency.

In general it's the poor ergonomics of calling native command-line tools and manipulating their results that tend to disappoint, but I've mostly played with CSX (c# repl script) as a "repl as command-line" dabbling.

In shell, "if" just looks at the exit status of the next set of commands.

if ls /path ; then echo foo ; fi

works just as well as the sugar wrapping "test" ( [ ] ) or extended builtins.

That's fine. But simple things that should work in order to be painless, don't.

-- -- bash:~]$ if $var < 21; then echo "smaller"; fi

bash: 21: No such file or directory

-- -- BUT this works:

if (( $var < 21 )); then echo "smaller"; fi

smaller

-- -- BUT this DOESN'T:

if [[$var < 21 ]]; then echo "smaller"; fi

bash: 21: No such file or directory

-- -- BUT this DOES (added a space after '[['):

if [[ $var < 21 ]]; then echo "smaller"; fi

smaller

Plus the fact that having to type out 'then' and 'fi' and that semi-colons are semi-necessary are annoying. Compared to today's languages, very little of the non-posix parts of bash feel well though out. We can do better.

All these things make it necessary to understand bash. Most modern programming languages feel familiar. Bash and Sh don't anymore. They feel antiquated.

I'm not defending shell, just pointing out how it works.

One of my biggest annoyances with shell is that there are these magic programs such as [ that pretend to be part of the language but aren't.

If if $var has an exit status (because perhaps you insanely want to have var be some program set elsewhere) your if statement would work....

These other examples have operators (test or similar expanded builtins), and those set the exist status that the if block reads.

so grep -q hacker < /etc/passwd if [ $? -eq 0 ] ; then echo hackd! ; fi

is an indirect way of saying:

if grep -q hacker < /etc/passwd ; then echo hackd! ; fi

Shell is terrible, but the way people use it makes it even worse because the sugar hides what's actually going on.

Meanwhile in zsh

    $ if (( $var < 21 )); then echo "smaller"; fi
    smaller
    $ if [[ $var < 21 ]]; then echo "smaller"; fi
    smaller
    $ if [[ $var < 21 ]] { echo "smaller" }
    smaller

I'm curious , if I type

"ls -la"

how does it know if it is "variable ls minus variable la", or "command list with command argument -la"?

It checks if the variables 'ls' and 'la' exist, and if they do, it'll run it as python. If not, it'll try to parse it as bash. If it can't parse it as bash, it'll try again in python mode.

https://xon.sh/tutorial.html#python-mode-vs-subprocess-mode

> It checks if the variables 'ls' and 'la' exist, and if they do, it'll run it as python. If not, it'll try to parse it as bash.

This is horrifying. It can break in so many unexpected and context dependent ways... Do people really run this shell on purpose?

There are edge cases but IME I rarely came across commands that could be valid python and valid bash. And you'll keep those in mind when you're running things so that you won't ever name a variable after a bash command you might use.

I ran it for a couple of years while I was in school, it worked great. I wouldn't run it on a production server, this is really for experimental work

I've been using it for a few years. It has its warts, but the problem you highlighted has never bitten me.

Holy crap that was my exact reaction to reading that. It’s just like bash: 99% of the time it’s an innocent thing, until suddenly you source some script that redefines something, innocently thinking it shouldn’t be a problem. That’s how you get an rm -rf.

Yeah you wouldn't source a script written for a different shell in this language, if that's a part of your workflow you'll want to either audit them first or you'll just want to drop into a bash shell.

I'm not sure how you end up rm -rf ing anything. 'rm -rf' by itself doesn't do anything, and if you do 'rm -rf .' that's no longer valid python. Not to mention that most people writing python would write 'rm - rf' if for some reason they had variables with those names (why would you name it that?) that they needed to subtract. And for some reason, you're not doing anything with the result of that subtraction.

If you're sourcing scripts without reading them, the source of the danger is that behavior, not your shell

> most people writing python would write 'rm - rf' if for some reason they had variables with those names (why would you name it that?) that they needed to subtract.

I can see myself naming variables that way, when doing a geometric computation. Being a mathematician, all my variable names are single letters. But sometimes I have variants of a name that merit a second letter, like a sub-index. Maybe I use "r" for the current radius of an object and "rm" for the "middle" radius and "rf" for the "final" radius after some polishing process. Then I want to see how much material I'm losing from the object in the middle. Thus "rm -rf" (yes, the missing space is a typo).

You need two typos in that you need to forget that space, and you also need to have forgotten to set one of those variables. You also don't actually delete anything until you name a file, so you'll need to add more valid python that's also a valid filename

In marcel this is a command:

   ls -l

And this is arithmetic:

    (ls -l)

In general, parens delimit arbitrary Python expressions.

https://marceltheshell.org

Reply on news.ycombinator.com