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.
>>
>> Obvi
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 location
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 documentati
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
>
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 shortcomin
[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
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 "$@"
> combina
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 destinati
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 manua
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(200
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
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
> 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
> +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 jus
> 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 wast
15 matches
Mail list logo
