On Fri, Sep 22, 2006 at 04:11:28PM -0400, Philip Ganchev wrote: > If you can store arbitrary text, it's more of a scratchpad than a > history.
very true. that's how i am and have been using the history all along. > How about using a delete buffer for it -- if the command line had > multiple buffers, you could paste from them in turn. Wouldn't this be > simpler? for hundreds of commands? i don't care how it is stored or how the storage is named. what matters is how i can access it. and that access is provided by the current history mechanism, namely browsing and searching commands with up/down arrow keys. any other way of accessing it would be harder. > With your proposal, the non-executed text would be stored together > with hundreds of executed commands, in the order of writing on the > command line. How would you fish it out when you need it -- string > search? i don't understand that question. i would access it just like current history items. > How would you know whether a given entry was actually executed? How > would you get a list of all executed commands, if you needed? i don't generally need that information. if i do need it then for me it would only be useful if the order of commands is kept intact (which is not the case, because doubles are removed) and i also would want it in a permanent log with timestamps and maybe even the return value. the current history does not tell me the order nor does it say how often or when a command has been executed. so it is not useful for statistics or any other things. > >i also want to be able to execute some commands without having them > >added to the history. > Why? to not pollute the history with lots of uninterresting commands. (history storage is limited. for any new command an old one needs to go.) or i accidently (or even deliberately, because there was no other option) supply sensitive information as an argument to a command. then it is nice to have the option to clear this out. granted this need happens very rarely, but it does come up occasionally. > How would you do that with a history variable -- delete them > manually after they are added? that, or i would write a function that i can call to do it. > Is it worth the conceptual and > practical complication? > >the history ought to be a pool of resources available to you, and not a > >log of what happened. > I thought that different resources are used in different ways, and so > should be accessible separately. if they are used in different ways. that is the point here. for me history and a scratchpad are one and the same. logging commands is something different. for logging the current history mechanism is not suitable. > >(ok, maybe history is not a good name for it then, > >but if it's a log it certainly doesn't need to be kept in memory) > I think the reason it is kept in memory is low latency of access. a log does not need that kind of access. a scratchpad does. > But, as I remember, reading the history file is the thing that most > slows down starting a new shell instance. maybe because it is the largest piece of data to be read at once. i have not noticed because i rarely start shells, i keep them running all the time with screen. 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/ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Fish-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
