Pádraig Brady wrote:
> Eric Blake wrote:
>> According to Pádraig Brady on 9/18/2009 8:21 AM:
>>> I'd vote for removing the translation help line unconditionally
>>
>> Hmm. The GNU Coding Standards don't mention the translation bug report
>> line, but the gettext manual recommends including it for
Pádraig Brady wrote:
...
> Subject: [PATCH] doc: mention the texinfo documentation in --help
Thanks!
Good catch on moving hard-locale.h inclusions back.
> * src/system.h: Rename emit_bug_reporting_address() to
> emit_ancillary_info() and update it to remove the translation
> project address and i
C de-Avillez wrote:
> On Fri, 18 Sep 2009 23:42:31 +0100
> Pádraig Brady wrote:
>
>> -emit_bug_reporting_address (void)
>> +emit_ancillary_info (void)
>
> Hi Pádraig,
>
> Thank you for getting the details done. Well, it really seems I still
> have a lot to learn on coreutils.
>
> But there is
Eric Blake wrote:
> According to Pádraig Brady on 9/18/2009 8:21 AM:
>> I'd vote for removing the translation help line unconditionally
>
> Hmm. The GNU Coding Standards don't mention the translation bug report
> line, but the gettext manual recommends including it for any program with
> i18n out
On Fri, 18 Sep 2009 23:42:31 +0100
Pádraig Brady wrote:
> -emit_bug_reporting_address (void)
> +emit_ancillary_info (void)
Hi Pádraig,
Thank you for getting the details done. Well, it really seems I still
have a lot to learn on coreutils.
But there is an issue in the change above: pretty much
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Pádraig Brady on 9/18/2009 8:21 AM:
> I'd vote for removing the translation help line unconditionally
Hmm. The GNU Coding Standards don't mention the translation bug report
line, but the gettext manual recommends including it for any pro
C de-Avillez wrote:
> On Fri, 18 Sep 2009 17:34:31 +0200
> Jim Meyering wrote:
>
>> Pádraig Brady wrote:
>>
>>> Alfred M. Szmidt wrote:
> Is there anyone who's unaware that --help doesn't provide
> complete documentation?
I would not expect anyone to *not* know that h
Lluís Batlle wrote:
> I'm using glibc 2.9, and gcc 4.3.4, and I can't build coreutils 7.6.
> Should I be able to build it?
>
> I get this build error:
> gcc -std=gnu99 -I. -g -O2 -c -o mkstemp.o mkstemp.cc
> mkstemp.c: In function 'rpl_mkstemp':
> mkstemp.c:43: error: too many arguments to f
Pádraig Brady wrote:
> Pádraig Brady wrote:
>> sleep $(seq .1 .1 4 | head -n $(($RANDOM%40 +1)) | tail -n1)
>
> Or more concisely using just coreutils logic:
>
> sleep $(seq .1 .1 4 | shuf | head -n1)
Or save a pipe+process:
sleep $(seq .1 .1 4 | shuf --head=1)
On Fri, 18 Sep 2009 17:34:31 +0200
Jim Meyering wrote:
> Pádraig Brady wrote:
>
> > Alfred M. Szmidt wrote:
> >>> Is there anyone who's unaware that --help doesn't provide
> >>> complete documentation?
> >>
> >>I would not expect anyone to *not* know that help output is
> >>abri
I'm using glibc 2.9, and gcc 4.3.4, and I can't build coreutils 7.6.
Should I be able to build it?
I get this build error:
gcc -std=gnu99 -I. -g -O2 -c -o mkstemp.o mkstemp.cc
mkstemp.c: In function 'rpl_mkstemp':
mkstemp.c:43: error: too many arguments to function 'gen_tempname'
Regards,
L
Pádraig Brady wrote:
> Alfred M. Szmidt wrote:
>>> Is there anyone who's unaware that --help doesn't provide
>>> complete documentation?
>>
>>I would not expect anyone to *not* know that help output is
>>abridged. But I would rather have them go straight into 'info'
>>than wa
Philip Rowlands wrote:
> On Fri, 18 Sep 2009, Pádraig Brady wrote:
>
>> Pádraig Brady wrote:
>>> sleep $(seq .1 .1 4 | head -n $(($RANDOM%40 +1)) | tail -n1)
>>
>> Or more concisely using just coreutils logic:
>>
>> sleep $(seq .1 .1 4 | shuf | head -n1)
>
> This still has the quantization effect
Alfred M. Szmidt wrote:
>> Is there anyone who's unaware that --help doesn't provide
>> complete documentation?
>
>I would not expect anyone to *not* know that help output is
>abridged. But I would rather have them go straight into 'info'
>than wasting time on 'man', only to b
I'm tempted to say add a one-liner, but there are already *four*
lines at the end of even the smallest --help output message, e.g.,
$ sync --help
Usage: sync [OPTION]
Force changed blocks to disk, update the super block.
--help display this help and exi
> Is there anyone who's unaware that --help doesn't provide
> complete documentation?
I would not expect anyone to *not* know that help output is
abridged. But I would rather have them go straight into 'info'
than wasting time on 'man', only to be redirected to 'info'.
Usually
C de-Avillez wrote:
> On Thu, 2009-09-17 at 11:59 -0700, Micah Cowan wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> C de-Avillez wrote:
>> > So. Would it be an acceptable idea to add, to the '--help', a warning
>> > that this is *not* the full documentation?
>> >
>> > Say, like:
On Fri, 18 Sep 2009, Pádraig Brady wrote:
Pádraig Brady wrote:
sleep $(seq .1 .1 4 | head -n $(($RANDOM%40 +1)) | tail -n1)
Or more concisely using just coreutils logic:
sleep $(seq .1 .1 4 | shuf | head -n1)
This still has the quantization effects which I'm trying to avoid. Jim's
perl su
On Fri, 18 Sep 2009, Eric Blake wrote:
However, it seems to me that your problem is that bash tries to slurp all
of $() into memory, and seq generated so much data that bash ran out of
memory (or overflowed its stack).
It's certainly possible for bash to run out of stack and crash with
SIGSEG
On Thu, 2009-09-17 at 11:59 -0700, Micah Cowan wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> C de-Avillez wrote:
> > So. Would it be an acceptable idea to add, to the '--help', a warning
> > that this is *not* the full documentation?
> >
> > Say, like:
> >
> > "This is an abridged
Eric Blake wrote:
> According to Jim Meyering on 9/18/2009 4:47 AM:
>> Assuming ln -s /nowhere dangling-symlink,
>> New behavior:
>>
>> $ ./readlink -fv dangling-symlink/
>> /nowhere
>>
>> Previous:
>>
>> $ readlink -fv dangling-symlink/
>> readlink: dangling-symlink/: No such file
Pádraig Brady wrote:
> sleep $(seq .1 .1 4 | head -n $(($RANDOM%40 +1)) | tail -n1)
Or more concisely using just coreutils logic:
sleep $(seq .1 .1 4 | shuf | head -n1)
cheers,
Pádraig.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Ryan Whited on 9/18/2009 4:38 AM:
> #!/bin/bash
> for i in $(seq -w $NUM1 $NUM2)
Are you sure your segfault is in seq, or is it in bash? You neglected to
mention which versions you were using:
bash --version
seq --version
However, it s
Here is my code.
#!/bin/bash
echo "Add directions here."
read URL
read NUM1
read NUM2
read EXT
echo "Please choose a folder name."
read NAM
mkdir $HOME/$NAM
cd $HOME/$NAM
for i in $(seq -w $NUM1 $NUM2); do wget "$URL${i}$EXT"; done
I was testing out my script, and I came across an instanc
Philip Rowlands wrote:
> This would help with some work I'm doing today, but is it of general
> interest?
>
> $ sleep --random 4.0
>
> sleeps for a random amount of time up to and including the requested
> value. The purpose is that on distributed systems it's disruptive to
> have synchronized scri
Philip Rowlands wrote:
> This would help with some work I'm doing today, but is it of general
> interest?
>
> $ sleep --random 4.0
>
> sleeps for a random amount of time up to and including the requested
> value. The purpose is that on distributed systems it's disruptive to
> have synchronized sc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 9/18/2009 4:47 AM:
> Assuming ln -s /nowhere dangling-symlink,
> New behavior:
>
> $ ./readlink -fv dangling-symlink/
> /nowhere
>
> Previous:
>
> $ readlink -fv dangling-symlink/
> readlink: dangling-sym
This would help with some work I'm doing today, but is it of general
interest?
$ sleep --random 4.0
sleeps for a random amount of time up to and including the requested
value. The purpose is that on distributed systems it's disruptive to
have synchronized scripts all starting up together. One
Dmitry V. Levin wrote:
> On Thu, Sep 10, 2009 at 07:29:35PM +0200, Jim Meyering wrote:
>> Eric Blake wrote:
>> > I think there are some infelicities in the canonicalization options of
>> > readlink.
>> >
>> > readlink -fv file/=> correctly reports ENOTDIR
>> > readlink -fv missing => lists /p
On Thu, Sep 10, 2009 at 07:29:35PM +0200, Jim Meyering wrote:
> Eric Blake wrote:
> > I think there are some infelicities in the canonicalization options of
> > readlink.
> >
> > readlink -fv file/=> correctly reports ENOTDIR
> > readlink -fv missing => lists /path/to/missing
> > readlink -fv
30 matches
Mail list logo
