5 ms·

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

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.

justinhj 8y ago
Weird. I learned these two things in the opposite order. I guess my first use of touch was to test out makefiles
dexterlagan 8y ago
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 8y 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 8y ago
    [deleted]
  - MR4D 8y 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 8y ago
      You can use "cd -" to go back to the previous directory.
      - lyk 8y ago
        $OLDPWD also holds the previous directory.
      - gabcoh 8y ago
        Does that work like a stack or does it just swap?
        kbp 8y ago
        It only swaps; you can use pushd and popd if you want a stack.
        kazinator 8y 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 8y ago
        If you use "mkdir -", bash will not change into this directory. Not even if you use "cd -- -". "cd ./-" works.
  - laumars 8y 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 8y 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 8y 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 8y ago
  To create a blank file, another idiom is "> foo".
jhbadger 8y ago
Oh, the update times feature is pretty common, at least among those who use a shared system where "scratch" files are deleted when they are seven days old.
- noobermin 8y ago
  Funny thing. I work in the computational field where we deal with TBs of data regularly. We are supposed to backup sim outputs to tape asap and using touch to modify modification times to avoid this is explicitly forbidden.
TeMPOraL 8y ago
I suppose this is a similar situation as with `cat' - it's meant to conCATenate stuff, but the most common usage I've seen (and one I've learned) is the idiom of `cat somefile | some-commands'. (Whenever I share a snippet with this idiom, I get told by one of my cow-orkers to stop abusing kittens...)
- klez 8y ago
  Isn't `some-command < somefile` more idiomatic (also, should spawn one process less)?
  - aepiepaey 8y ago
    Yes. See "Useless use of cat" (or "UUOC"). 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 instead of grep pattern file.txt or cat file.txt | grep pattern There are also some related useless uses, like useless use of grep | awk: grep pattern file | awk '{print $3}' which can instead be written as awk '/pattern/ {print $3}' file

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.

justinhj 8y ago

Weird. I learned these two things in the opposite order. I guess my first use of touch was to test out makefiles

dexterlagan 8y ago

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 8y 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 8y ago
  [deleted]
- MR4D 8y 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 8y ago
    You can use "cd -" to go back to the previous directory.
    - lyk 8y ago
      $OLDPWD also holds the previous directory.
    - gabcoh 8y ago
      Does that work like a stack or does it just swap?
      - kbp 8y ago
        It only swaps; you can use pushd and popd if you want a stack.
        kazinator 8y 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 8y ago
      If you use "mkdir -", bash will not change into this directory. Not even if you use "cd -- -". "cd ./-" works.
- laumars 8y 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 8y 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 8y 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 8y ago
To create a blank file, another idiom is "> foo".

jhbadger 8y ago

Oh, the update times feature is pretty common, at least among those who use a shared system where "scratch" files are deleted when they are seven days old.

noobermin 8y ago
Funny thing. I work in the computational field where we deal with TBs of data regularly. We are supposed to backup sim outputs to tape asap and using touch to modify modification times to avoid this is explicitly forbidden.

TeMPOraL 8y ago

I suppose this is a similar situation as with `cat' - it's meant to conCATenate stuff, but the most common usage I've seen (and one I've learned) is the idiom of `cat somefile | some-commands'. (Whenever I share a snippet with this idiom, I get told by one of my cow-orkers to stop abusing kittens...)

klez 8y ago
Isn't `some-command < somefile` more idiomatic (also, should spawn one process less)?
- aepiepaey 8y ago
  Yes. See "Useless use of cat" (or "UUOC"). 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 instead of grep pattern file.txt or cat file.txt | grep pattern There are also some related useless uses, like useless use of grep | awk: grep pattern file | awk '{print $3}' which can instead be written as awk '/pattern/ {print $3}' file