On 8/25/06, Martin Bähr <[EMAIL PROTECTED]> wrote: > On Fri, Aug 25, 2006 at 07:07:59PM +0200, Axel Liljencrantz wrote: > > >interactive and script behaviour is different. > > >or the other way around: > > >someone finds a script, and thinks, ah, i just need this once, why bother > > >putting it in a file? i'll just copy and paste it into the shell. > > I hadn't thought of it that way. Unfortunatly, there is no way around > > this problem that I can see. So one has to weigh the benefit against > > the drawbacks. Hard call. > > what are the drawbacks?
When I said drawbacks I was talking about the script vs. commandline differences you where describing. I've been thinking about ways to fix the assignment-for-single-command problem without introducing script vs. commandline differences. One way would be to introduce a new switch to set, -s / --single-command: set -s CC icc; make would mean set the value of CC to icc, but only for the make command. May be ok. > > my apologies if that is a dumb question, obviously i am not familiar > with fish internals, but my naive view of this would be: what is the > problem with keeping the state of blocks in interactive mode? > don't you have to do the same thing while interpreting a script? There is no problem. What you are suggesting is how fish has always worked. My suggestion was to change this, to make each line a separate block in order to make it possible to assign a new value to a variable for the scope of a single command without manually creating a block. > > keeping the state would even allow some neat things like changing the > prompt for the lines that follow, to alert the user that they are in a > a block now. (like python does it) Once there is mutiline editing, I fully plan to do that through the use of automatic indentation. > > this seems to be leading into a discussion of how to do the multiline > editing mode, i hope that's ok. Sure. > > in any case i for the reasons i gave i would like to see compatibility > of script and interactive mode as a longterm goal, unless there are some > good arguments against that. The argument against this compatibility is that it allows you to change the value of a variable for a single command easily, which can be very useful. But this is probably not a strong enough argument. There are ways to do it without such undesirable side effects. > > > >(provisions to catch someone pasting bash code by somehow ignoring any > > >input as soon as something wrong comes in > > Fish already does quite a lot of cleverness when it comes to keyreading: > > nice, then that suggestion is not something completely out of place. Not at all. > > 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
