4 ms·

You don't lack imagination, but I bet you didn't really try to think about what you could do. When you first dive into Linux, you learn that you have a thousan

• jamesbritt 14y ago
  You do that because nobody told you what they were for, they just were. I do that because I've seen previous examples of these things, often cases of solving a real problem, and then go from there. Yes there are times I see some set of tools and just mess with them and make stuff up, but really I only have so many hours in a day for that and other things. FWIW I think most people dive into Linux because they already had an idea of what they expected it to do for them. Perhaps Xiki really can do assorted cool and novel things. Or maybe it just does familiar things in a cool way. That's much less interesting to me.
• roryokane 14y ago
  Your mentioning people “start[ing] using [commands] in ways their programmers never imagined” reminded me, a shell newbie, of something I had read a long time ago, which was that people who use `cat` to output a single file’s contents are using the program for something other than its intended purpose. That inspired me to experiment to find the correct way of echoing file contents. I think the correct way is the `<` operator. `>` writes to a file, and `<` is the inverse, so it reads from a file. One shouldn’t `cat some-file.txt` or `cat some-file.txt | wc -l`; one should `< some-file.txt` or `< some-file.txt | wc -l`. `cat` is only necessary when you supply to it multiple arguments, as in `cat first-file.txt second-file.txt`. Of course, `cat` still works for outputting file contents, as it has for me all this time. But it just feels more “right” and “safe” to use the operator that is built for that purpose. I just wanted to mention that discovery in case anyone else wondered the same thing when they read the words about using commands in unintended ways.
  • cgs1019 14y ago
    Given the proximity of `<` and `>`, and the fact that `> somefile.txt` will silently truncate the file, I would take issue with the "safeness" claim :P Also, `< file.txt | wc` doesn't work (at least not in bash; zsh (my install/plugin combo, at least) apparently tries to map the lone `< file.txt` to `less -R file.txt`...which spits out an error. Anyway, omitting the pipe will work: `< file.txt wc -l` `cat` by definition concatenates one or more files and spits the output to stdout, so using it on a single file is perfectly within the bounds of its definition (IMHO; I realize people get really zealous about this type of thing and I'm not trying to start a war).
    • pwg 14y ago
      > and the fact that `> somefile.txt` will silently truncate the file Bash has the "set -C" option to toggle on "no-overwrite" mode for redirection operators.
      • Evbn 14y ago
        But it's obnoxiously not set by default.
        • deleted 14y ago
          [deleted]
        • sequoia 14y ago
          This might screw up some POSIX shell scripts if they expect to be able to write a tmp file or overwrite one if it already exists.
      • gnosis 14y ago
        zsh also has a "setopt NO_CLOBBER", but it's also not the default (unfortunately). Default behavior: % touch foo % echo bar > foo % cat foo bar % rm foo No clobber mode: % setopt NO_CLOBBER % touch foo % echo bar > foo zsh: file exists: foo Manual override: % echo bar >| foo % cat foo bar
    • 14y ago