4 ms·

Thanks! I implemented this just to create blank files, and didn't bother researching correctness. That's exactly the kind of correction I was hoping for when po

Thanks! I implemented this just to create blank files, and didn't bother researching correctness. That's exactly the kind of correction I was hoping for when posting to HN. My first post too.

akkartik 9y ago
Another minor issue: cd without arguments should switch to the home directory rather than display the current directory (as your Readme suggests you do). You already have pwd for displaying the current directory.
- deleted 9y ago
  [deleted]
- MR4D 9y ago
  Unless you’re seven directories deep and accidentally hit the <enter> button instead of the <shift> button. In which case, uh, you want the current functionality.
  - Cerium 9y ago
    You can use "cd -" to go back to the previous directory.
    - lyk 9y ago
      $OLDPWD also holds the previous directory.
    - gabcoh 9y ago
      Does that work like a stack or does it just swap?
      - kbp 9y ago
        It only swaps; you can use pushd and popd if you want a stack.
        kazinator 9y ago
        Also: - "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.
    - kazinator 9y ago
      If you use "mkdir -", bash will not change into this directory. Not even if you use "cd -- -". "cd ./-" works.
- laumars 9y ago
  'cd' is generally a shell built-in (even with Bash) rather than a forked command so I think it's fair if shell writers want to break the mold with that particular function. It's like how the shell built-in versions of 'echo' usually differ from /bin/echo (same for 'time' as well). 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.
  - akkartik 9y ago
    I don't understand your argument at all. Whether something is a builtin or not is an implementation detail. 'cd' actually can't be anything but a builtin. 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'.
    - laumars 9y ago
      > I don't understand your argument at all. 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.
kazinator 9y ago
To create a blank file, another idiom is "> foo".

Thanks! I implemented this just to create blank files, and didn't bother researching correctness. That's exactly the kind of correction I was hoping for when posting to HN. My first post too.

akkartik 9y ago

Another minor issue: cd without arguments should switch to the home directory rather than display the current directory (as your Readme suggests you do). You already have pwd for displaying the current directory.

deleted 9y ago
[deleted]
MR4D 9y ago
Unless you’re seven directories deep and accidentally hit the <enter> button instead of the <shift> button. In which case, uh, you want the current functionality.
- Cerium 9y ago
  You can use "cd -" to go back to the previous directory.
  - lyk 9y ago
    $OLDPWD also holds the previous directory.
  - gabcoh 9y ago
    Does that work like a stack or does it just swap?
    - kbp 9y ago
      It only swaps; you can use pushd and popd if you want a stack.
      - kazinator 9y ago
        Also: - "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.
  - kazinator 9y ago
    If you use "mkdir -", bash will not change into this directory. Not even if you use "cd -- -". "cd ./-" works.
laumars 9y ago
'cd' is generally a shell built-in (even with Bash) rather than a forked command so I think it's fair if shell writers want to break the mold with that particular function. It's like how the shell built-in versions of 'echo' usually differ from /bin/echo (same for 'time' as well). 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.
- akkartik 9y ago
  I don't understand your argument at all. Whether something is a builtin or not is an implementation detail. 'cd' actually can't be anything but a builtin. 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'.
  - laumars 9y ago
    > I don't understand your argument at all. 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.

kazinator 9y ago

To create a blank file, another idiom is "> foo".