5 ms·

Maybe I lack imagination, but even though the tool provides many interesting solutions, it doesn't seem to "scratch an itch" for any problems I need to solve.

• vasco 14y ago
  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 thousand different simple commands. And you feel kinda lost. Then you start using them in ways their programmers never imagined. And you chain them with pipes and do some really cool shit. You do that because nobody told you what they were for, they just were.
  • 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
• trogdoro 14y ago
  There are other screencasts on xiki.org/screencasts that go into detail about specific scenarios. Some of them are a little out of date but the general idea is till the same. The one on web development is decent but needs an update. More screencasts to come soon. I've gotten similar feedback, re imagining what it would be used for. The simplest use case is probably the "shell terminal but better" one. You can narrow down the output of shell commands, and make reusable files with notes as you run stuff (for yourself to use later on, or for other people). You can nest the commands underneath directory paths to avoid having to CD. You can change parts of the paths to re-run the same commands in a parallel dir structure in a different place (even a remote server). You can search command history in a specific dir and re-run commands (vs bash history showing you commands that were run in any dir). You can post any notes you made on the web or email them to people, for others to help others get started using stuff. Going a bit higher-level, Xiki sort of lets you have "paths" (kind of analogous to url's) for many different things - database records, running commands in specific dirs, running a line of javascript in your browser, changing the style of a div, firing off a button click on a web page given its id, running unit tests, showing runnable (and modifiable) example code for various frameworks, etc. Most people probably agree that having paths for files and web pages is pretty useful. Having paths to other things can be useful for many of the same reasons.