I'm embarrassed I don't use a shell often enough to really say, but off the top of my head:
- Avoid confusion between layers and bypass escaping entirely. The paradigm for "being a metacharacter" is not "being one of this subset" or "following a certain character" but is "entered from the keyboard in a different way, eg. by holding a modifier key" and "is displayed in a different colour, different width, or other non-text way".
- Alternatively, a step down would be to have ONE metacharacter that's rarely used by programs (perhaps even a special unicode character?) that always precedes a metacharacter. This makes simple commands longer, but long commands saner and at this point may be a worthwhile tradeoff. (Like using $var in perl -- it's more verbose, but clearer, which perl REALLY needs).
- The first suggestion could even be implemented in terms of the second suggestion, if the shell does everything in #1 but stores it internally like #2. That way, you CAN edit it raw if you have to.
- Programs accept arguments from the shell not in one undifferentiated sequential glob of text, but through different routes which implicitly determine what's a filename, what's an option, and what's general text. You could escape options similarly to metacharacters using the techniques in 1 and 2, and the shell could provide keyboard commands to specifiy which was which, but perhaps normally what you type into the appropriate sort. (Perhaps syntax-hilighted so you can see when something's wrong.) You might go even further than the shell does and specify a fixed relationship for when program options have parameters, and the eventual program receieve input in some simple nested arrays or something, notionally like (opt 1 (filename params) (other params)) (opt 2 (filename params) (other params)) (opt 3) (flag 1) (general filename input). [Although some shells sort of do this already?]
What I was trying to say in the pub, but perhaps needed to be written down instead, is that many of our ideas are quite far-reaching, but perhaps the idea of having _one_ unusual escape character with the shell, with or without special keys/graphics to indicate it, would be a comparatively superficial change to an existing shell, and might be worth trying as an experiment -- I've never implemented a shell in any way, and probably won't try this one, but someone more confident might well be able to do so without too extensive a modification of an existing one...?
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
- Avoid confusion between layers and bypass escaping entirely. The paradigm for "being a metacharacter" is not "being one of this subset" or "following a certain character" but is "entered from the keyboard in a different way, eg. by holding a modifier key" and "is displayed in a different colour, different width, or other non-text way".
- Alternatively, a step down would be to have ONE metacharacter that's rarely used by programs (perhaps even a special unicode character?) that always precedes a metacharacter. This makes simple commands longer, but long commands saner and at this point may be a worthwhile tradeoff. (Like using $var in perl -- it's more verbose, but clearer, which perl REALLY needs).
- The first suggestion could even be implemented in terms of the second suggestion, if the shell does everything in #1 but stores it internally like #2. That way, you CAN edit it raw if you have to.
- Programs accept arguments from the shell not in one undifferentiated sequential glob of text, but through different routes which implicitly determine what's a filename, what's an option, and what's general text. You could escape options similarly to metacharacters using the techniques in 1 and 2, and the shell could provide keyboard commands to specifiy which was which, but perhaps normally what you type into the appropriate sort. (Perhaps syntax-hilighted so you can see when something's wrong.) You might go even further than the shell does and specify a fixed relationship for when program options have parameters, and the eventual program receieve input in some simple nested arrays or something, notionally like (opt 1 (filename params) (other params)) (opt 2 (filename params) (other params)) (opt 3) (flag 1) (general filename input). [Although some shells sort of do this already?]