the first rule of bash is Never Use Double Quotes

the first rule of cmd.exe is Never Use Single Quotes

every time I git commit on Linux I end up doing something like:

git commit -m "add unit-tests for `(lambda)` closures"

and then bash sees the grave characters inside of the double quotes and is like “ohohoho! you fool!”

every time I type a special character in bash it’s like it was waiting all day for me to make that mistake

@kasdeya I have an idea for a shell that doesn't have that problem. Haven't gotten to trying to code it up yet, though.

@static ooh how would it work?

@kasdeya I realized the key is to remove all the complex quoting rules and just make the script a proper language where literal strings must be quoted and variables are concatenated.

The other half making that work is having a second default parsing mode for the command line that doesn't permit variable interpolation at all. To do that, you switch to the script mode for just that command and use the proper language tools.

@kasdeya So you could do normal things like change directories and run programs, but if you wanted a variable, well you do this:

q echo "My current path is " PATH

Which means you could do:

q echo "The first item in my path is " PATH.split(":")[0]

@static oohhh - I really like this! like I can instantly tell what this is doing instead of it being a mess of special characters like a lot of bash scripts look like to me lol

@kasdeya Yeah - that's part of the impetus.

I've got a document exploring/describing this I've been adding to over the last few months. Been experimenting with notation along the way, too. I'd kinda like to be able to write stuff like this:

q echo "My first path item is " PATH split: "." at: 0

... but I need to have a further think about the parse trees to do that. I'm drawing from a lot of different languages, JavaScript/TypeScript, BASIC, Python perhaps, even Smalltalk.

@kasdeya Inside a script file, it defaults to "quoted" mode so you don't need the "q" prefix. Instead, if you want the plain mode for one line, you use "ex". So inside a script, instead having to do:

cd "path/to/a/file"

you could do:

ex cd path/to/a/file

@kasdeya first rule of bash (and most other similar shells) is always use double quotes when variables are involved unless you're sure you want literals.

whenever i have spaces in a string stored as a variable, unless I want it chopped up into arguments or something, I always need double quotes

@static @kasdeya How would you handle paths with spaces? That's something that's typically required either quotes or escaping to ensure that its passed to the program being run as a single argument and not two.

@kasdeya for committing i never use -m, i always let it open my text editor instead to write message instead

ive enabled verbose commit as well, so this way also allows me to double check the changes i'm actually committing

it is annoying in other cases though

@StryderNotavi @kasdeya In quoted mode, the space would be inside the string with the path. Inside a script, that would be the obvious way to do it and how you would be expected to do it.

So:

q cd "./a path/with/spaces"

In executable mode, I was thinking of adding only a minimum of quoted string support. So:

ex cd "./a path/with/spaces"

.... would also work as expected. Basically, everything between a matching pair of quotes is a single string. In both modes. Inside double, quotes, you use "" to put a single ".

Single quotes, though, would support the C-style \escapes but nothing else.

@StryderNotavi @kasdeya @static all of this sounds quite similar to https://xon.sh

@static @kasdeya oh so powershell

@Lunaphied @StryderNotavi @kasdeya Interesting! I am not surprised someone has tried this before.

I'm having a look, but I can immediately see some philosophical differences. It would be a bit too Python for my tastes, TBH.

@static @Lunaphied @StryderNotavi I looked into it in the past because I love Python, but one thing that it does that I find very cursed is:

IIRC, the way that it determines whether something is Python or a shell command is that it tries to run it as Python, and if it gets a syntax error it runs it as a shell command instead. or maybe vice-versa. but that sounds like it carries a lot of potential footguns with it

@arichtman @kasdeya I hadn't considered Powershell. Oh - I did not know it was available on non-Windows systems.

Ooh... PowerShell has a _very_ different philosophy. Cool idea, and I can see why they did it, but not what i was trying to do.

@static @StryderNotavi @kasdeya iirc that's not actually what it does it might try to parse it as python but I don't even think it's that simple. I use it and in practice it comes up never that something caused some weird behavior. The worst thing that happens is you misquote and get confused why enter doesn't just run what you entered.

As for betting overly pythonic I can see it but in practice the implicit behavior is enough that I rarely actually do anything python-y in the shell itself

@static @StryderNotavi @kasdeya the main benefit of the pythony part is when writing scripts it makes it way easier to deal with command pipelines

@Lunaphied @StryderNotavi @kasdeya My original impulse was to vastly simplify the quoting problem. I don't think xon.sh really addresses that.

That's a good comment about handling command pipelines, though. That is another concern I had with bash.

@static @StryderNotavi @kasdeya I'm not sure why you'd think that about quoting? It's vastly simplified in Xonsh

@Lunaphied @StryderNotavi @kasdeya Not quoting, variable use. I mis-typed. Environment variables seem to have their own namespace, for instance.

@kasdeya @static @StryderNotavi no they're actually not in their own namespace! it's a bit overly cute and weird about it because it has to extend Python to allow the more generic referencing to them, but it's technically just a normal variable this section is recommended if you haven't read it https://xon.sh/tutorial.html#environment-variable

I will note that occasionally you'd really like it to not do the auto processing for PATH type variables and the tutorial should be updated with better instructions on that

@Lunaphied @kasdeya @StryderNotavi I think that takes us back to my original comment about how close it is to Python. :)

Not that that's bad, just not what I was aiming to do.

@StryderNotavi @static @kasdeya yeah fair! It's just worth checking out and if theres anything you think could be improved you can always file a bug!