On 8/22/06, Martin Bähr <[EMAIL PROTECTED]> wrote: > On Tue, Aug 22, 2006 at 03:17:56AM +0200, Axel Liljencrantz wrote: > > > that said, half of the time i find myself trying to use fish style > > > history in a bash. > > I won't be happy until you never find yourself using bash. :) > > on my notebook currently the only use of bash is for root, since i am > not yet sure i want to trust fish that much. on the other hand, the more > i use fish the more i like it, and thus the more i stay away from the > root shell, and that's actually good thing.
Since I am usually using an experimental development snapshot of fish, I do the same. So I don't blame you there. > > the other thing that keeps me from using fish for root is the lack of a > kill builtin. the reason for that is, that sometimes the machine can be > so loaded that forking a new command fails. in such situations a builtin > kill function is potentially the only way to potentially stop runaway > processes. This is a tough one. This is really a kernel bug - the kernel should be able to preoperly distribute CPU time so that interactive tasks are reasonably responsive even under load. But it is a kernel bug that is very easy to partially fix in user space through the addition of a kill builtin. It is tempting, but I really don't want to do that. I want to avoid builtins whenever possible, for the reasons outlined in previous mails and on this page: http://roo.no-ip.org/fish/user_doc/design.html > > and then there are a number of debian servers where i am not the main > administrator,where i would first need to get consent to be allowed to > install fish, since fish is not in debian stable. (but once etch is out > that will be easier to argue) Jamessan (the Debian fish packager) to the rescue! > > > > namely for a command that just prints the history to stdout, > > The $history environment variable contains the last 10 entries form > > ahh, didn't think about that one. > > > It would be easy to extend this to contain the entire history. > > that would be nice. Will do, then. > > > Would a builtin command be better? > > i don't think so. having the history in a variable should open up even > more interesting ways to manipulate it. and in the worst case it would > just take a loop to pipe all entries through grep. You would be able to do both always, since they provide the same functionality. The main differences are in discoverability and ease of use. Relevant points: * Fish uses a 'random' builtin instead of a $RANDOM varaible as bash does, because it really is more a function than a variable (It changes dynamically every time you use it, but always in the same order - that's pretty far from how other variables work), and because I though it would be easier to find out about a builtin than a function. * $history allows you to do neat things like array slicing because it is an array and fish has some pretty nice tools for manipulating arrays. > > > 'commandline -t' should do just that. > > ah, yes, thanks. > i saw -t but in the description above it somehow i only saw > updated and missed that it also mentioned printing commandline is pretty powerful. You can get, remove, replace or append to either the current commandline, the current job, the current process or the current token. Only thing missing is moving the cursor. I'll add that as well eventually. Should be pretty easy, I hope. > > > That lets you use Meta-x to enter a new command, which can in turn > > operate to the contents of the previous commandline. > > that part escapes me. how do i get the entered command to operate in > the previous commandline? If you use e.g. the commandline builtin in the command you entered using M-x, the builtin will operate on the original commandline. So a very cumbersome way to erase the contents of the current commandline would be to press M-x and enter the command 'commandline ""'. > > > Sure. Along a related path, it was suggested some time ago that event > > hooks be added that are fired before a commandline command is > > executed. > > that would be interresting. > > > That way a sed script could be run on the commandline before > > executing it, which would transform Posix shellscript into fish > > shellscript. > > ??? Imagine if the following script was run before every command was executed: commandline (commandline | sed -e "s/done/end/") If it was, then you could write for i in *.c; echo $i; done and it would be transformed to for i in *.c; echo $i; end If one would do this with every incompatibility between Posix and fish, then... Ugh, it would be horrible. But having the possibility is cool. > > > making fish extensible enough to allow you to do things like that > > would be pretty cool. > > indeed, i can see a lot of other uses: logging, help for beginners > (paperclip style: hey, it looks like you want to change your directory, > do you want to ...? ;-) Almost as bad an idea as the one above. :-] > > > If you have a design for a complete replacemnt of the current history > > search, or a separate system that completemnts the current system in a > > nice way and is significantly more powerful, feel free to provide a > > detailed description. > > i am considering to experiment in the direction of something that > actually displays the matching history entries, or at least a screenful > of them. Let me know if you come up with a complete solution. > > btw, to implement incremental search a trigger on each keypress would be > useful... That's pretty much exactly what a key-binding is. You can bind a function to e.g. the 'a' button, you know... You can also change the key binding in response to a key event. That is what the currently half-finished vi-mode that ships with fish does. The idea to expose key events through the regular fish event mechanism has come up before. the argument against it is that it mean there are two ways to do key-bindings, which is silly and confusing. On the other hand, I've sometimes though that the readline compatibility with /etc/inputrc is more trouble than it's worth. It's mostly there because some distributions use /etc/inputrc to fix common terminfo problems, like delete not working in some emulators. I thought that piggybacking on that information would be a good idea, but since fish and readline have somewhat different abilities, this is not always a perfect match. So there is a possibility that some day in the future, the _only_ way to specify a key binding is to do something like: function ctrl_c --on-key \3; ...; end > > greetings, martin. > -- > cooperative communication with sTeam - caudium, pike, roxen and unix > offering: programming, training and administration - anywhere in the world > -- > pike programmer travelling and working in europe open-steam.org > unix system- bahai.or.at iaeste.(tuwien.ac|or).at > administrator (caudium|gotpike).org is.schon.org > Martin Bähr http://www.iaeste.or.at/~mbaehr/ > -- Axel ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Fish-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
