Fun Unix Trivia Time: Touch is supposed to update modified times. That it creates files when they don't exist is only the most common use, not the point of the thing.
So in that regard I don't think it's fair to compare 'cd' to 'cat' nor 'touch' where people will be used to the GNU / whatever coreutils.
The behavior of 'cd' is defined by the Posix standard (in spite of it needing to be a builtin). Now, you're welcome to care or not about that. But there's no reason to make that decision inconsistently for 'cd', 'cat' and 'touch'.
I sense you're misunderstanding something, namely that POSIX defines not only the names and behavior of a number of common utilities, but also the shell language. There is no "in spite"; POSIX defines the shell syntax features like while, case, if, the various expansions that the shell does and so forth.
By your reasoning, someone's original shell-like scripting language must not have a case statement that is not terminated by esac, and that doesn't have cases terminated by ;; because POSIX requires these. I.e. one mustn't develop a program and call it a "shell" if it isn't a POSIX conforming shell.
cd is a shell feature like while or case; it's effectively a special assignment operator for mutating the shell's current working directory.
My point being shell builtins can and often do differ from one shell to another.
> Whether something is a builtin or not is an implementation detail.
You could argue that but I think it goes a little beyond purely implementation detail. A builtin is often a builtin because it fits the shell idiom better than having a forked command. eg `time` wouldn't work well if you had to put the command you want timed in quotation marks; which is one of the reasons Bash includes it's own `time` function as a builtin despite `/bin/time` being arguably more powerful (there are other reasons but I feel this is going to be a lengthy reply and `time` vs `/bin/time` is already well documented online anyway)
Thus if this shell's idiom is simplicity over features then it makes some sense not to follow Bash's convention for `cd`. In fact if I can use myself as an example; I have also written my own shell I didn't follow Bash's convention for `cd` either (which means I'm also aware `cd` cannot be anything other than a built in :P) The reason I broke compatibility with `cd` was because I wanted historic directories in a stacked array by default; I don't support `pushd` / `popd` because `cd` does it right out of the box. The historic variable holds the previous directories in a JSON array and that better fits the idioms of my shell because my shell is designed around natively munging data structures such as JSON. Thus my builtins should also follow the same idioms as the rest of the shell regardless of whether that breaks POSIX compliances or not.
> The behavior of 'cd' is defined by the Posix standard (in spite of it needing to be a builtin).
In case you hadn't noticed, this isn't a POSIX shell. There's no law stating every $SHELL has to be POSIX compliant and in fact a lot are not; including Bash itself. So your point about POSIX compliance is not relevant here at all as if you want a fully POSIX compliant shell then you should be looking elsewhere.
> Now, you're welcome to care or not about that. But there's no reason to make that decision inconsistently for 'cd', 'cat' and 'touch'.
Again I feel the need to reiterate the point that one runs a different shell because they lean towards a different idiom. So with that regard there is every reason to make a decision for breaking standards on `cd` if those standards don't conform to your shells own idioms. Otherwise what the hell is the point of running an alternative shell?
I feel `cat` and `touch` are exceptions to this rule because they are traditionally forked. I mean by all means the author is welcome to re-implement some of coreutils as well if they wish (ala Busybox) but I personally feel that is a step too far in shell design (excluding for a moment my previous example of Busybox as that is clearly intended as a one stop shop and is very useful in that regard!). I think the saner approach if you want to offer alternative functions to coreutils is to offer alternative builtins (eg `lcat` for "Lisp cat"). However that is my personal preference and if this particular shells author wants to reimplement coreutils for whatever reason they choose then I wish them luck. If nothing else, it will teach them a new appreciation for GNU et al coreutils.
I absolutely encourage that! I accepted that possibility in my comment. See the kind of stuff I build: https://github.com/akkartik/mu. I introduced Posix purely as an example that builtins are as subject to standardization as coreutils.
Other than clarifying that I'll agree to disagree. It's great to rethink a shell from the ground up. If you're doing that, what earlier shells happen to choose as a builtin is an irrelevant signal. Depending on how you design your idioms, it may make sense to override stuff from coreutils as builtins. As you've pointed out, such overriding has already happened in bash and other shells.
These are all artificial boundaries to be questioned. Decide what behavior you want to copy and what you want to rethink regardless of where you find it.
It's pretty clear this shell isn't intended to follow in the footsteps of Bash, let alone be fully POSIX compliant, so I don't really understand why you are comparing it to them in terms of compatibility (and even more confused now that you've said you encourage people breaking POSIX).
Or is the point you're raising a question of what should be a builtin and what should not?
(happy to agree to disagree by the way; but I'm just a little confused as to what we are disagreeing about :))
Set aside my mention of POSIX as a minor point. My basic claim is this: building a whole new shell is an ambitious act. Whether your goal is to create a better experience for others or just learn new skills, restricting yourself to what earlier shells happen to consider to be builtins is limiting ambition. Be more ambitious and rethink as much as you want.
I'm not saying you have to rethink everything all at once all the way up from machine code (though I'm sympathetic to and experienced in that particular failure mode ^_^). I'm saying if you have an idea to improve 'cat' to fit better with your new shell, the fact that it's in coreutils shouldn't cause you pause. Who cares if it's a builtin in bash or not? Make it a builtin in your shell.
In which case, uh, you want the current functionality.
- "cd -" has no interaction with the pushd/popd stack except in the sense that it alters the top of the stack (the current working dir). It doesn't swap the two top entries of the directory stack, but swaps the top with an off-stack saved location ($OLDPWD).
- "pushd" with no arguments swaps the top two stack entries.
(Whenever I share a snippet with this idiom, I get told by one of my cow-orkers to stop abusing kittens...)
If you prefer to have the command arguments at the end of the line (so it's easier to amend), you can do e.g:
< file.txt grep pattern
grep pattern file.txt
cat file.txt | grep pattern
grep pattern file | awk '{print $3}'
awk '/pattern/ {print $3}' file