> Hi Bo,
>
> Thanks for that patch.
>
> However, let's see if Cai Xianchao and Li Zefan
> are still working on rewriting cp to use openat-style functions.
>
I am sorry for replying so late. :-[
I am busy recently, so the development speed is very slow.
I have finished the work as follows:
Bonjour;
j'ai deux principaux problèmes qui me dérangent:
-pilote de carte graphique non détecté : aucune accélération graphique et
Kubuntu ignore ma carte graphique Nvidia Ge Force7100 Gs
-pas de son : je ne peus pas avoir du son.
Merci.
J'attend votre Réponse.
__
After being burned by using `head -c6 /dev/urandom | base64` as part of a
directory name, I realised that it would be useful if base64 had an option to
generate URL and Filename safe encodings, as specified in RFC 3548 section 4.
This would make
cat FILE | base64 --filename-safe
equivalent to
ca
I noticed that chcon and runcon were exempted from some of the tests
in misc/help-version. That exemption (probably back from when I added
preliminary versions) was hiding this small defect:
>From bbc0cb0f37641b1779170b3e15bd3479fb250fed Mon Sep 17 00:00:00 2001
From: Jim Meyering <[EMAIL PROTECT
Christopher Kerr wrote:
> After being burned by using `head -c6 /dev/urandom | base64` as part of a
> directory name, I realised that it would be useful if base64 had an option to
> generate URL and Filename safe encodings, as specified in RFC 3548 section 4.
>
> This would make
> cat FILE | bas
Christopher Kerr wrote:
> After being burned by using `head -c6 /dev/urandom | base64` as part of a
> directory name, I realised that it would be useful if base64 had an option to
> generate URL and Filename safe encodings, as specified in RFC 3548 section 4.
>
> This would make
> cat FILE | bas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Pádraig Brady on 4/29/2008 6:59 AM:
| Perhaps `tr '+/' '._'` would be better so that
| you don't need to worry about "-" at the start of a filename?
Which is worse - a file that can be confused with an option, or a file
that is hidden by
Pádraig Brady wrote:
> Perhaps `tr '+/' '._'` would be better so that
> you don't need to worry about "-" at the start of a filename?
I'm think `.' at the beginning of a filename also has the potential to
give users unexpected behavior.
Bo
___
Bug-c
Bo Borgerson <[EMAIL PROTECTED]> wrote:
> Christopher Kerr wrote:
>> After being burned by using `head -c6 /dev/urandom | base64` as part of a
>> directory name, I realised that it would be useful if base64 had an option to
>> generate URL and Filename safe encodings, as specified in RFC 3548 secti
Christopher Kerr <[EMAIL PROTECTED]> wrote:
> After being burned by using `head -c6 /dev/urandom | base64` as part of a
> directory name, I realised that it would be useful if base64 had an option to
> generate URL and Filename safe encodings, as specified in RFC 3548 section 4.
>
> This would make
Bo Borgerson wrote:
> Pádraig Brady wrote:
>> Perhaps `tr '+/' '._'` would be better so that
>> you don't need to worry about "-" at the start of a filename?
>
>
> I'm think `.' at the beginning of a filename also has the potential to
> give users unexpected behavior.
Doh! never thought of that
Jim Meyering meyering.net> writes:
> > ./bootstrap: m4/xsize.m4 overrides ._bootmp2/m4/xsize.m4
> > Undefined subroutine &Test::test_vector called at tests/mk-script line 44.
> > ./bootstrap: aclocal --force -I m4 ...
>
> Thanks for reporting that.
> Would you please pull the latest to see if Bo
Eric Blake <[EMAIL PROTECTED]> wrote:
> Jim Meyering meyering.net> writes:
>> > ./bootstrap: m4/xsize.m4 overrides ._bootmp2/m4/xsize.m4
>> > Undefined subroutine &Test::test_vector called at tests/mk-script line 44.
>> > ./bootstrap: aclocal --force -I m4 ...
>>
>> Thanks for reporting that.
>> W
Pádraig Brady draigBrady.com> writes:
> tr '+/' '._' => hidden files
> tr '+/' '-_' => awkward option clashes
> tr '/' '_' => not POSIX portable
>
> ho hum, the awkward option clashes is probably best.
You can always use ./ prefix to avoid option clashes, and for most tools, you
can also use -
Pádraig Brady wrote:
> tr '+/' '._' => hidden files
> tr '+/' '-_' => awkward option clashes
> tr '/' '_' => not POSIX portable
>
> ho hum, the awkward option clashes is probably best.
Yeah, there's no really ideal option, is there...
It almost might be nice to have a totally user-configurable a
On 04/29/2008 4:47:53 PM +0200, Bo Borgerson <[EMAIL PROTECTED]> wrote:
Pádraig Brady wrote:
tr '+/' '._' => hidden files
tr '+/' '-_' => awkward option clashes
tr '/' '_' => not POSIX portable
AFAIK, POSIX filenames allow any character except the slash character
and the null byte.
ho hum
Gabriel Barazer wrote:
> AFAIK, POSIX filenames allow any character except the slash character
> and the null byte.
>
> Especially when this is the RFC recommanded translation. This would
> avoid confusing people with multiple translation sets and stick to the
> RFC (considered by many as the autho
Gabriel Barazer <[EMAIL PROTECTED]> writes:
> On 04/29/2008 4:47:53 PM +0200, Bo Borgerson <[EMAIL PROTECTED]> wrote:
>> Pádraig Brady wrote:
>>> tr '+/' '._' => hidden files
>>> tr '+/' '-_' => awkward option clashes
>>> tr '/' '_' => not POSIX portable
>
> AFAIK, POSIX filenames allow any charac
If you're reading this list, you probably noticed that some kind
souls at Stanford uncovered a surprising number of bugs in coreutils
recently. Part of their analysis was coverage-related, and they
produced these coverage reports:
http://keeda.stanford.edu/~cristic/coreutils-dev-tests/src/
I
Jim Meyering wrote:
> If you're reading this list, you probably noticed that some kind
> souls at Stanford uncovered a surprising number of bugs in coreutils
> recently. Part of their analysis was coverage-related, and they
> produced these coverage reports:
>
> http://keeda.stanford.edu/~cri
Bo Borgerson <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> If you're reading this list, you probably noticed that some kind
>> souls at Stanford uncovered a surprising number of bugs in coreutils
>> recently. Part of their analysis was coverage-related, and they
>> produced these coverage re
Hi,
> How cool!
>
> That's a really useful tool. I wonder if it might be possible to
> include some instructions for producing a coverage report like that in
> the project somewhere... maybe in the HACKING file?
It is fairly straightforward, although lcov has some quirks resolving path
names whi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wow! Check out the speedup with this patch, comparing an -O2 /bin/cut
pre-patch against an unoptimized -g cut post-patch, and that's even with
running /bin/cut second so it benefits from any file system caching effects.
$ dd count=20k data
20480+0
23 matches
Mail list logo
