Re: feature request: configurable history timestamps
On Sun, Dec 18, 2011 at 3:26 AM, Chet Ramey wrote: > On 12/11/11 1:13 AM, Alex Shinn wrote: > >> I had initially been confused by the HISTTIMEFORMAT >> variable thinking it could be used to change what was >> written to the history file, rather than the output of the >> history command. >> >> Obviously it would have to be a separate variable, but >> the ability to add extra info to the history file would be >> very useful to me. Given the pid and pwd you can >> effectively track sessions, and know where you invoked >> a command in addition to when. >> >> As a simple change, just statically appending the bash >> pid such that the history file looks like: >> >> #1323582935 217 >> command >> >> would enable constructing a session and inferring the >> pwd by checking for cd/pushd/popd commands (assuming >> no other aliases or scripts are used to chdir). > > One question is whether or not this would be of general interest, since > any user-specified text to append to the timestamp would have to come > after the timestamp and be more-or-less ignored by the history code proper. > (and the timestamp would have to be inserted unconditionally). What's the > use case? Third-party forensics? You can already use HISTFILE to break > out history by session, so this would only be worth it if you insisted on > using a single history file for all shell sessions. Yes, I do insist on this - I want ^R and history search to be able to search all my sessions. -- Alex
Is the description of set -- missing in man bash or at least difficult to find?
Hi,
As I mentioned previously, there are shortcomings in man bash. Here, I
just point another example. And I hope my suggestion will be
addressed.
As a reasonable search strategy to search for how to set $@ is to
search for '$@' in man bash. The literal word '$@' appears at the
following locations.
...performed, with the exception of "$@" as explained below under Special...
...expands to a separate word. That is, "$@" is equivalent to "$1"...
...When there are no positional parameters, "$@" and $@ expand to...
...of "$@" and "${name[@]}" as explained above (see PARAMETERS)...
Search for 'set --' returns nothing. And search for '--' is prohibited
as there are too many of them. If the manual discusses how to 'set
$@', then it is at least hard to find. My suggestion is to add a new
paragraph to the existing discussion of $@, so that by searching $@,
readers can easily see how set $@.
@ Expands to the positional parameters, starting from one. When
the expansion occurs within double quotes, each parameter
expands to a separate word. That is, "$@" is equivalent to "$1"
"$2" ... If the double-quoted expansion occurs within a word,
the expansion of the first parameter is joined with the begin-
ning part of the original word, and the expansion of the last
parameter is joined with the last part of the original word.
When there are no positional parameters, "$@" and $@ expand to
nothing (i.e., they are removed).
As others pointed out LDP/abs is a more readable document, the
following link is a much better document on helping me to find how to
set "$@".
http://tldp.org/LDP/abs/html/internalvariables.html
--
Regards,
Peng
Re: Is the description of set -- missing in man bash or at least difficult to find?
On Thu, Dec 22, 2011 at 12:09:38PM -0600, Peng Yu wrote:
> As a reasonable search strategy to search for how to set $@ is to
> search for '$@' in man bash.
There is a "Special Parameters" section. All of the parameters are listed
there without their leading $ prefix. For example, the documentation for
$@ is found in the section marked with an @ under Special Parameters.
I submitted a patch to try to get the sections to be labeled with $@
(etc.) so that people could find them, but the patch was not accepted.
> Search for 'set --' returns nothing.
There is nothing special about -- with respect to the set command. The
special option -- to ANY COMMAND (except echo) means "there are no
more options". Everything after that is a non-option argument. (In
the case of set, non-option arguments become the new positional
parameters.)
It is traditional to use set -- foo bar baz to set the positional
parameters, just in case the first argument happens to begin with a -.
In this example, it could just as well be written set foo bar baz
and that would have precisely the same effect. You only need the --
when you have an expansion in the first argument, as in set -- "${a[@]}"
> As others pointed out LDP/abs is a more readable document, the
> following link is a much better document on helping me to find how to
> set "$@".
... I don't get it. You clearly already KNOW how to set the positional
parameters, because you mentioned "set --" previously. You said you
were searching for set --, which means you KNEW about it, and were just
looking for some details.
You can't say that you are searching for set -- and then, in the same
email, say that you don't know how to set the positional parameters.
One of these things must be a lie.
If you are serious about trying to improve the documentation, then submit
a patch. Maybe you'll have more success than I did.
If you just want to get into a fight about the documentation, please go
somewhere else.
Of course the "ABS" is a more readable document, flawed as it is, because
it's trying to TEACH you how to write bash scripts. The bash manual is
not trying to teach you how to write scripts. It is a REFERENCE manual.
Please understand the difference between a tutorial and a reference manual.
Re: Is the description of set -- missing in man bash or at least difficult to find?
Greg Wooledge wrote: > Peng Yu wrote: > > As a reasonable search strategy to search for how to set $@ is to > > search for '$@' in man bash. > > There is a "Special Parameters" section. All of the parameters are listed > there without their leading $ prefix. For example, the documentation for > $@ is found in the section marked with an @ under Special Parameters. > > I submitted a patch to try to get the sections to be labeled with $@ > (etc.) so that people could find them, but the patch was not accepted. +1 vote on getting the parameters listed with a leading dollar sign. The individual single character is difficult to search for but the combination of "$@" and so forth for the others is a useful search string. I have often wanted the manual to include the "$@" combination instead of just the "@" name. Bob
Re: Is the description of set -- missing in man bash or at least difficult to find?
On Thu, Dec 22, 2011 at 01:09:38PM EST, Peng Yu wrote: > Hi, > As I mentioned previously, there are shortcomings in man bash. Here, > I just point another example. And I hope my suggestion will be > addressed. [..] Here's my suggestion, and nothing needs to be ‘addressed’. There are shortcomings in _the man documentation format_ and one of them is that it doesn't work (at least for me...) when the documentation is longer than one screen or thereabouts. I've pretty much come to the conclusion that any man page that is over a couple of hundred lines is a waste of my time and should probably not even exist in the first place. What I did: $ info bash Then I selected the last entry: ‘Indexes’, then the ‘Variable Index’ and then... I searched for ‘@’... and found exactly what I was looking for! Took about three seconds! In order to find more about ‘set’, I did the same, choosing the ‘Builtin index’ instead of the ‘Variable Index’... and found everything I'll ever need to know about ‘set’ before anyone has time to say Bob's your uncle. Not to mention that I didn't waste anyone's time and bandwidth opening a ‘bug report’... :-) Be aware that in the event info's rather peculiar user interface is too much of a hassle, you may find that the ‘pinfo’ derivative might better suit your needs. CJ
'>; ' redirection operator [was: [1003.1(2008)/Issue 7 0000530]: Support in-place editing in sed (-iEXTENSION)]
[cc'ing bash, dash, mksh, and zsh developers; feel free to avoid
cross-posted replies on content not relevant to all the groups]
On 12/22/2011 08:39 AM, David Korn wrote:
> Subject: Re: Re: [1003.1(2008)/Issue 7 530]: Support in-place editing in
> sed (-iEXTENSION)
>
>
> There are many commands other than sed that want the output to replace
> an input file. That is why I added the >; redirection operator to ksh93.
>
> With >; you can do
> sed -e s/foo/bar/ file >; file
> to do in place sed. The >; operator generates the output in a temporary file
> and moves the file to the original file only if the command terminates
> with 0 exit status.
I agree that engineering a single fix into the shell that can apply to
multiple situations, rather than chasing down a set of applications to
add an in-place editing option to each, is a much more flexible and
powerful approach. Can we get buy-in from other shell developers to
support '>;' as an atomic temp-file replacement-on-success idiom, if
POSIX were to standardize the existing practice of ksh93 as the basis?
I assume on the ksh implementation that the temp file is discarded if
the command (simple or compound) feeding the redirection failed? If the
redirection is used on a simple command, is there any shorthand for
specifying that the destination name on success also be fed as an
argument to the command, to avoid the redundancy of having to type
'file' both before and after the '>;' operator? I assume that this is
like any other redirection operator, where an optional fd number can be
prepended, as in '2>; file' to collect stderr and overwrite file on
success? What happens if there is more than one '>;' redirection in the
same command, and both target the same end file (whether or not by the
same file name)? What happens if the command succeeds, but the rename
of the temp file to the destination fails? Are there clobber ('>|') or
append ('>>') variants?
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: Is the description of set -- missing in man bash or at least difficult to find?
Bob Proulx wrote: > +1 vote on getting the parameters listed with a leading dollar sign. > The individual single character is difficult to search for but the > combination of "$@" and so forth for the others is a useful search > string. I have often wanted the manual to include the "$@" > combination instead of just the "@" name. I haven't become familiar with the info format until now. As acceptable workaround even for long manuals I usually search for the keyword as first word in a line (where it likely introduces the paragraph describing it). In this case it works as well: /@ Quite interesting dilemma, that while you are (well, at least me) thinking of $VAR, it's usually about VAR outside of nerd writing :)
Re: '>;' redirection operator [was: [1003.1(2008)/Issue 7 0000530]: Support in-place editing in sed (-iEXTENSION)]
On 12/22/11 13:03, Eric Blake wrote: I assume on the ksh implementation that the temp file is discarded if the command (simple or compound) feeding the redirection failed? One would hope! If the redirection is used on a simple command, is there any shorthand for specifying that the destination name on success also be fed as an argument to the command, to avoid the redundancy of having to type 'file' both before and after the'>;' operator? Doesn't the shell already have enough hieroglyphs? It is what intimidates many folks from figuring it out. I assume that this is like any other redirection operator, where an optional fd number can be prepended, as in '2>; file' to collect stderr and overwrite file on success? When the exact opposite is the useful variation? I.e. keep-on-failure. "-i" for sed is simple, understandable and implemented a lot. Please don't add another glyph to the standardized shell. Let us not slide on slippery slopes. Shells can always add some useful builtins: sh_move_if_changed sh_save_on_success sh_save_on_failure to cope with this stuff. Or you can write your own such library for your own use. ">;" is not an answer for sed-as-a-batch-editor anyway, which is what "-i" really is.
Re: Is the description of set -- missing in man bash or at least difficult to find?
Sven Mascheck writes: > Bob Proulx wrote: > >> +1 vote on getting the parameters listed with a leading dollar sign. >> The individual single character is difficult to search for but the >> combination of "$@" and so forth for the others is a useful search >> string. I have often wanted the manual to include the "$@" >> combination instead of just the "@" name. > > I haven't become familiar with the info format until now. > As acceptable workaround even for long manuals I usually > search for the keyword as first word in a line (where it > likely introduces the paragraph describing it). > > In this case it works as well: > /@ There is an index entry for @, so i @ RET brings you directly to the description of the @ special parameter. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: '>; ' redirection operator [was: [1003.1(2008)/Issue 7 0000530]: Support in-place editing in sed (-iEXTENSION)]
cc: ebl...@redhat.com bug-bash@gnu.org d...@vger.kernel.org
miros-disc...@mirbsd.org
Subject: Re: '>;' redirection operator [was: [1003.1(2008)/Issue 7 530]:
Support in-place editing in sed (-iEXTENSION)]
> On 12/22/2011 08:39 AM, David Korn wrote:
> > Subject: Re: Re: [1003.1(2008)/Issue 7 530]: Support in-place editi=
> ng in sed (-iEXTENSION)
> >
> >=20
> > There are many commands other than sed that want the output to replace
> > an input file. That is why I added the >; redirection operator to ksh9=
> 3.
> >=20
> > With >; you can do
> > sed -e s/foo/bar/ file >; file
> > to do in place sed. The >; operator generates the output in a temporar=
> y file
> > and moves the file to the original file only if the command terminates
> > with 0 exit status.
>
> On 12/22/2011 16:04 AM,Eric Blake wrote:
> I agree that engineering a single fix into the shell that can apply to
> multiple situations, rather than chasing down a set of applications to
> add an in-place editing option to each, is a much more flexible and
> powerful approach. Can we get buy-in from other shell developers to
> support '>;' as an atomic temp-file replacement-on-success idiom, if
> POSIX were to standardize the existing practice of ksh93 as the basis?
>
> I assume on the ksh implementation that the temp file is discarded if
> the command (simple or compound) feeding the redirection failed? If the
Yes.
> redirection is used on a simple command, is there any shorthand for
> specifying that the destination name on success also be fed as an
> argument to the command, to avoid the redundancy of having to type
> 'file' both before and after the '>;' operator? I assume that this is
> like any other redirection operator, where an optional fd number can be
> prepended, as in '2>; file' to collect stderr and overwrite file on
> success? What happens if there is more than one '>;' redirection in the
> same command, and both target the same end file (whether or not by the
> same file name)? What happens if the command succeeds, but the rename
> of the temp file to the destination fails? Are there clobber ('>|') or
> append ('>>') variants?
No, it only works if the file specified with >; is a regular file.
How could it know which command argument to use for the name, for example
cat foo bar >; /dev/fd/2
how would it know whether to use foo or bar?
If there is more than one >; command, then ksh will create a temporary file
for each of these but will only the last one will get standard out.
Thus the first one will be replaced by and empty file and the second one
will get the output if successful. Thus
command ... >; f1 >; f2
is equivalent to
command ... > f1 >; f2
There is no clobber or append variants. Append doesn't wipe anything out so
it is not needed.
I also added the operator <>; which is the same as <> except that the file
is truncated on close. Thus,
tail -s 100 file <>; file
will remove the first 100 lines of a file and will not require extra
temporary disk space.
>
David Korn
d...@research.att.com
Re: Is the description of set -- missing in man bash or at least difficult to find?
Andreas Schwab wrote: > Sven Mascheck writes: > > I haven't become familiar with the info format until now. > > As acceptable workaround even for long manuals I usually > There is an index entry for @, [...] I was probably too short, I meant searching a tradititional man page. Sven
Re: '>;' redirection operator [was: [1003.1(2008)/Issue 7 0000530]: Support in-place editing in sed (-iEXTENSION)]
2011/12/22 Bruce Korb > > When the exact opposite is the useful variation? I.e. keep-on-failure. > "-i" for sed is simple, understandable and implemented a lot. > As far as I know, -i is only implemented with GNU sed and BSD sed, and they are incompatible, BSD sed's -i takes a mandatory argument, while GNU sed's -i takes an optional string which must be provided in the same argument. E.g. gnused -i.bak sed-script file bsdsed -i .bak sed-script file So the only portable way of using sed to "edit" (read: overwrite) a file is with sed sed-script file > file.tmp && mv file.tmp file I'd welcome this >; syntax. -- Geir Hauge
Re: Is the description of set -- missing in man bash or at least difficult to find?
> Second, just search for the 'set' builtin, near the bottom of the man page. Thank for clarifying the usage of set. I looked closely to the document of set. I just find another problem, it says the following. However, the description of -- way down below. It should be the option be described. A rule of thumb is that the order of the description of the options should be the same as the order in the following line. set [--abefhkmnptuvxBCEHPT] [-o option-name] [arg ...] But my main point is if a person only knows the keyword $@, he will not be able to find how to set it in the manual. The description of 'set --' should also be added to the description of $@ to explain how to set $@. Also, "If no arguments follow this option, then the positional parameters are unset. Otherwise, the positional parameters are set to the args, even if some of them begin with a -." should be rewritten as "If no arguments follow this option, then the positional parameters $@ are unset. Otherwise, the positional parameters $@ are set to the args, even if some of them begin with a -." so that $@ is searchable. -- Regards, Peng
Re: Is the description of set -- missing in man bash or at least difficult to find?
> +1 vote on getting the parameters listed with a leading dollar sign. > The individual single character is difficult to search for but the > combination of "$@" and so forth for the others is a useful search > string. I have often wanted the manual to include the "$@" > combination instead of just the "@" name. I agree $@ is better than @. But not to repeat myself again, did you get my major point that I have restated to DJ Mills? -- Regards, Peng
Re: Is the description of set -- missing in man bash or at least difficult to find?
> There are shortcomings in _the man documentation format_ and one of them > is that it doesn't work (at least for me...) when the documentation is > longer than one screen or thereabouts. I've pretty much come to the > conclusion that any man page that is over a couple of hundred lines is > a waste of my time and should probably not even exist in the first > place. Hi CJ, You didn't get my point. Please see my reply to DJ Mills, if my first email is not clear enough to you. The shortcomings is not in the man format. Even if it is in the man format, it can be compensated in the way that I mentioned. -- Regards, Peng
