On 1/5/07, Philip Ganchev <[EMAIL PROTECTED]> wrote: > On 9/22/06, Martin Bähr <[EMAIL PROTECTED]> wrote: > > On Fri, Sep 22, 2006 at 11:21:29AM +0300, Beni Cherniavsky wrote: > [Philip Ganchev wrote:] > > > > I think the history is conceptually a builtin, because you can't set > > > > it (and should not be able to). > > > Why shouldn't I set it? > > > > yes, i also would like to be able to add commands to the history with > > out executing them. often i am working on a command, then i realize i > > need to do something else first. at that point it would be nice to > > add the command to the history to serve as memory and be able to come > > back to it later. > > Perhaps another reason why it should be a command is that as a > variable it becomes useless, supposedly because of the large number of > entries which builds up fast. I don't know what is the maximum number > of arguments, but this is what happens: > > fish> echo $history | more > fish: Failed to execute process "/bin/echo" > execve: Invalid argument > fish> count $history > fish: Failed to execute process "/usr/local/bin/count" > execve: Invalid argument > fish> count "$history" > fish: Failed to execute process "/usr/local/bin/count" > execve: Invalid argument > fish> wc -l .config/fish/fish_history > 22279 .config/fish/fish_history
That is indeed a problem. I remember reading an interview with one of the Unix creators (maybe it was Richie?) about what dissapointed him in modern Unix/Linux versions, and he mentioned that he thought it was silly that there where still so many arbitrary system limits, like the maximum number of arguments passed to execve. He had hoped we would have moved to dynamic allocations by now. Though I agree with him, that is really not in the scope of fish. > > Hurray for the fish_history file! (Actually, I think the file should > be called .config/fish/history, because the "fish_" part is > cacophonous. The same with "fish_inputrc" and "fish_read_history".) I thought so at first too. Only each part of fish that has a history gets it's own file. Currently, there are two separate histories, one for the main fish binary (fish_history) and one for the read buitin (read_history). It would be possible to give the main history the name 'history' but it would be inconsistent. It may make sense to allow you to specify a history name for the read builtin. That way you can write shellscripts which prompy the user and provide a history unique to that script. > > ------------------------------------------------------------------------- > 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 > -- Axel ------------------------------------------------------------------------- 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
