Re: history writes to process substitution but errors reading it
On Wed, Feb 19, 2025, at 9:48 PM, Dale R. Worley wrote: > What it is really doing is "declare foo to > be the history file, and then read its contents and put them in the > history list". The problem as I see it is that the easiest to spot part > of the documentation is > > -r Read the contents of the history file and append them to > the current history list. > > which states the (secondary) reading but doesn't mention the (primary) > setting of what the history file *is*. > > What I'd prefer is something like > > -r Set filename (or $HISTFILE) to be the history file. > Read the contents of the history file and append them to > the current history list. > > That emphasizes the primary effect of the command. What? As Andreas already explained, ''history -r foo'' reads foo, and ''history -r'' reads $HISTFILE. That's it. The documentation refers to "the history file" to avoid saying "_filename_ (or $HISTFILE if _filename_ is not specified)" over and over and over, but "the history file" is not a meaningful bit of state that the shell keeps track of. You invented it out of thin air. (If anything counts as "the history file", surely it's $HISTFILE.) -- vq
Re: history writes to process substitution but errors reading it
Andreas Schwab writes: > On Feb 14 2025, Dale R. Worley wrote: > >> And really, that means that the effect of -r is kind of complicated and >> unintuitive. > > Not really. The command uses either the supplied filename or $HISTFILE > to name the file to operate on. Other than that, the filename argument > has no effect. Of course, intuitive is in the mind of the reader. But from my point of view, I look at "history -r foo" and see "read the contents of foo and put it in the history list". What it is really doing is "declare foo to be the history file, and then read its contents and put them in the history list". The problem as I see it is that the easiest to spot part of the documentation is -r Read the contents of the history file and append them to the current history list. which states the (secondary) reading but doesn't mention the (primary) setting of what the history file *is*. What I'd prefer is something like -r Set filename (or $HISTFILE) to be the history file. Read the contents of the history file and append them to the current history list. That emphasizes the primary effect of the command. Dale