On 8/23/06, Philip Ganchev <[EMAIL PROTECTED]> wrote: > On 8/22/06, Axel Liljencrantz <[EMAIL PROTECTED]> wrote: > [...] > > 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: > > I guess the only reason a builtin may be less discoverable than a > variable is that there are much fewer variables (and that other shells > use a variable).
I would say that magic variables are less discoverable than builtins. It's easier to find builtins, either through tab completion or through the documentation. It just fits better with the workflow. 'help history' works, but 'help $history' doesn't. I'm not sure, but I doubt Doxygen will accept a $history section, so 'help \$history' probably won't work either. And as mentioned in the design document for fish, I try to make everything into a command. That is the reason that unlike in Posix, for/while/end and friends behave as much as possible like regular commands. > > > * 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. > > By the way, is there a reason why "random" should not be an external > program instead of a builtin? Excellent question. Yes, there is. By specifying the same seed twice, you should be able to reliably get the same series of random numbers twice, no matter what random numbers are generated by other shell instances. This is very important in order to provide repeatability when debuging. To implement an external random command that provides you with this feature, you'd need to save session state for every fish process, something like having a file in the users home directory containing the current seed of every process that's called the random command. While theoretically possible, it would be, in my opinion, a big enough mess to implement properly, that it's pretty far from worth it. > > > * $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. > [...] > > I think you are saying that if "history" was a builtin, then using > array splicing would be more verbose: ``set history (history); echo > $history[2]``. I guess this can be alleviated by using a hack like > ``(history | get 2 4)``. Of course, it would be nicer if > ``(history)[2 4]`` worked. Cool. Way to think outside of the box. I need to think/test for any possible pitfalls with that one, but if there are none, I will definitely implement this. -- 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
