Post a Comment
Also not to be confused with "The Fish", the rc.conf editor for FreeBSD.
http://www.energyhq.es.eu.org/thefish.html
It is less responsive than bash partly because it is parsing what I type as I am typing it. It has some cool concepts (like ending everything with 'end' and not 'fi' etc.) but it just does not feel the same.
The syntax highlighting is neat, but kind of better left off to a full editor. If it is long enough to need a script, you are probably going to use an editor. If it is short enough to stick on one line, 90% the time the handholding of higlighting portions of what I am typing is not needed. So that part of it is as annoying as it is useful IMHO.
The largest gains I see are marginal changes to the command syntax at the expense of breaking compatibility.
Edited 2005-12-19 19:46
Java-OO-shell? What exactly are you talking about, if then Monad is Java like, not Fish. I've just read through some of the material about fish and I like it. The syntax is clean (the first time I looked at long bash scripts I got scared by the syntax) and the designee ideas are very Unix like.
I still have to actually try it but I think I have myself a new favorite shell.
"Stop it. There's nothing new to this. Monad IS in fact innovative and has by FAR the better concepts than e. g. those ugly Java-OO-shells."
Please submit an article to OSNews with your analysis / comparison of various *nix shells and Monad. As far as I can see; Fish has nothing to do with Java; however, I await your write up on OSNews.
I often find my self whishing for some default buffer where the last output was saved.
That's what redirection was invented for :
$ cat somefile | grep some_shit | sort
OR
$ grep some_shit > /tmp/tmpfile
$ sort /tmp/tmpfile
That's what the pipe is : a temporary (circular) buffer that holds the output of the executing command. And if you feel you need to break it down into several steps you dump it into a temporary file.
I know what a pipe is ;-), it was the tmpfile thing I'd like to avoid, I usually end up with a lot of them.
Mostly it's when after a costly operation (du -a / f.ex.) realizing that, f*ck I should've sorted that and it needs some sed magic.
A simple command like
$ > buffer.txt
to save the buffer for further analysis would have saved me a few hours.
I know what a pipe is ;-),
I kinda guessed you did, but I thought I'd throw it in just in case for less advanced osnews'ers.
it was the tmpfile thing I'd like to avoid, I usually end up with a lot of them.
Yeah, the problem is ofcourse where to put this buffer. If you put it in memory then there's a risk of filling up the system memory if some process goes haywire. Even worse if you want to allocate seperate buffers for the different streams.
I guess you could create seperate files on disk somewhere to hold the output, maybe 3 named pipes in which you could dump the data dynamically compressed. I don't think that that would be to difficult to implement actually.
Myself I just use a client with good logging capabilities (putty) when connecting from windows, or the "script" command when I think I might want to have a more permanent log of my actions.
How about named pipes? Granted, they make use of mkfifo, but they can be reused, unlike anonymous pipes.
See: http://www2.linuxjournal.com/article/2156
I am pretty sure there is a bash-specific way to do this, but I can't remember what it is off the top of my head.
Edited 2005-12-20 11:14
Didn't they yank monad after a bunch of holes were found in it overnight after the very first preview?
No, it's still in development and is available as a seperate download and with the Windows/WinFX SDK (and I believe the WinFX runtime redist).
There were no holes found. There was publication of "viruses", that were just Monad scripts that wouldn't even run in the default configuration as scripts aren't associated with the Windows shell by default, and they are required by default to be signed before you can run them.
http://www.leeholmes.com/blog/MonadAndTheFirstVistaVirus.aspx
Fish will hopefully eventually support vi-bindings. Some code is already there, but a lot is still missing.
As to performance, the editor is sometimes amazingly slow because of inefficient repaint code. This will be improved in the future. If you run into any other performance issues, please report them on the mailing list, and they will be investigated.



