-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 4/16/2008 2:33 AM:
| This test would fail not only because the built-in mknod
| doesn't support -Z, but because it doesn't know about 'p' pipes.
|
| tests: avoid mkdir/selinux failure when mknod is a shell built-in
Eric Blake [EMAIL PROTECTED] wrote:
According to Jim Meyering on 4/16/2008 2:33 AM:
| This test would fail not only because the built-in mknod
| doesn't support -Z, but because it doesn't know about 'p' pipes.
|
| tests: avoid mkdir/selinux failure when mknod is a shell built-in
| *
Hello!
On Wed, Apr 16, 2008 at 02:30:57PM +0200, Jim Meyering wrote:
Eric Blake [EMAIL PROTECTED] wrote:
According to Jim Meyering on 4/16/2008 2:33 AM:
| This test would fail not only because the built-in mknod
| doesn't support -Z, but because it doesn't know about 'p' pipes.
|
|
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 4/16/2008 6:30 AM:
| My first reaction was great! that looks much better.
| Unfortunately, the technique doesn't work with that shell:
|
| openbsd$ ./mknod --version|head -1
| mknod (GNU coreutils) 6.10.188-7cb24
|
Jim Meyering [EMAIL PROTECTED] writes:
Unfortunately, the technique doesn't work with that shell:
openbsd$ ./mknod --version|head -1
mknod (GNU coreutils) 6.10.188-7cb24
openbsd$ PATH=. /bin/sh -c 'mknod --version'|head -1
What about /bin/sh -c 'exec mknod --version'?
Andreas.
--
Thomas Schwinge [EMAIL PROTECTED] wrote:
On Wed, Apr 16, 2008 at 02:30:57PM +0200, Jim Meyering wrote:
...
My first reaction was great! that looks much better.
Unfortunately, the technique doesn't work with that shell:
openbsd$ ./mknod --version|head -1
mknod (GNU coreutils)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 4/16/2008 6:57 AM:
| $ PATH=. /bin/sh -c 'exec mknod --version'|head -1
| /bin/sh: mknod: --: unknown option
Ouch - this looks like a POSIX compliance bug in exec; I'm adding
bug-autoconf to the distribution in case
Eric Blake [EMAIL PROTECTED] wrote:
According to Jim Meyering on 4/16/2008 6:57 AM:
| $ PATH=. /bin/sh -c 'exec mknod --version'|head -1
| /bin/sh: mknod: --: unknown option
Ouch - this looks like a POSIX compliance bug in exec; I'm adding
bug-autoconf to the distribution in case we want
Eric Blake [EMAIL PROTECTED] wrote:
According to Jim Meyering on 4/16/2008 6:57 AM:
| $ PATH=. /bin/sh -c 'exec mknod --version'|head -1
| /bin/sh: mknod: --: unknown option
Ouch - this looks like a POSIX compliance bug in exec; I'm adding
bug-autoconf to the distribution in case we
Hi Eric,
* Eric Blake wrote on Wed, Apr 16, 2008 at 03:07:42PM CEST:
According to Jim Meyering on 4/16/2008 6:57 AM:
| $ PATH=. /bin/sh -c 'exec mknod --version'|head -1
| /bin/sh: mknod: --: unknown option
Ouch - this looks like a POSIX compliance bug in exec; I'm adding
bug-autoconf
Matthew Woehlke [EMAIL PROTECTED] wrote:
Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 4/16/2008 6:30 AM:
| My first reaction was great! that looks much better.
| Unfortunately, the technique doesn't work with that shell:
|
| openbsd$
Matthew Woehlke [EMAIL PROTECTED] wrote:
$ /bin/sh -c '(exec mknod --version)' | head -1
$ /bin/sh -c 'nice mknod --version' | head -1
$ /bin/sh -c 'nohup mknod --version' | head -1
I realize you already pushed something, but for the record, wouldn't
env' work as well (and without the side
Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 4/16/2008 6:30 AM:
| My first reaction was great! that looks much better.
| Unfortunately, the technique doesn't work with that shell:
|
| openbsd$ ./mknod --version|head -1
| mknod (GNU coreutils)
Ralf Wildenhues Ralf.Wildenhues at gmx.de writes:
case bug in the shell portability section. POSIX states that exec is
supposed to bypass shell builtins (and while special shell builtins, like
'exit', give undefined behavior when passed to exec, regular shell
builtins, like 'fg', are
Hello list,
md5sum with the -c option did not work on files with \r\n and \r line
endings.
A patch is attached.
With best regards,
Simon Hengel.
=== modified file 'src/md5sum.c'
--- src/md5sum.c 2008-04-16 15:51:12 +
+++ src/md5sum.c 2008-04-16 16:27:50 +
@@ -465,7 +465,12 @@
Hello,
Running du -sk on an apache disk cache containing 10GB of data and
30,000 directories and files
I see du using maybe .03% of the cpu. It takes an hour for it to complete.
Are there any plans to make du multi-threaded? Or otherwise improve
it's performance?
Is it filesystem
Utility: df
Didn't know where to send these suggestions but two things that would be
nice...
1. Colour. Show different file system types (ie nfs) in a different
colour
2. Adjustable width. I have my screen width at about 142 characters
wide.That way the nfs mounts aren't taking up
This addresses a FIXME in src/copy.c:
-/* FIXME: rewrite this to use a hash table so we avoid the quadratic
- performance hit that's probably noticeable only on trees deeper
- than a few hundred levels. See use of active_dir_map in remove.c */
The performance benefit is there,
[ re-added bug-autoconf ]
* Eric Blake wrote on Wed, Apr 16, 2008 at 08:04:23PM CEST:
Subject: [PATCH] Document pdksh exec behavior.
* doc/autoconf.texi (Limitations of Builtins) exec: New
subsection.
Discovered by Jim Meyering.
This looks good to me, thanks.
Cheers,
Ralf
dd handles skip weirdly
disk=/dev/sda8
dd if=$disk bs=8M count=1 skip=1000 of=/dev/null #ok
dd if=$disk bs=8M count=1 skip=1000K of=/dev/null #reads whole disk! as seek
fails
I had a 10s look at the source and noticed a comment
saying POSIX doesn't specify what we should do when
skipping past
We are in the cutover process and one of the DBAs found this behavior.
If testfile1 is owned by usera:group1 in a parent directory with
permissions 777 owned by usera:group1, userb:group2 can delete testfile1
even if testfile1 has permissions 600. Conversely if the same parent
directory has
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to James J. Perry on 4/16/2008 4:25 PM:
| We are in the cutover process and one of the DBAs found this behavior.
| If testfile1 is owned by usera:group1 in a parent directory with
| permissions 777 owned by usera:group1, userb:group2 can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Simon Hengel on 4/16/2008 10:37 AM:
| Hello list,
| md5sum with the -c option did not work on files with \r\n and \r line
| endings.
|
| A patch is attached.
Thanks for the patch, but it corrupts actual \r in file names on platforms
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to rh on 4/16/2008 12:14 PM:
| Hello,
| Running du -sk on an apache disk cache containing 10GB of data and
| 30,000 directories and files
| I see du using maybe .03% of the cpu. It takes an hour for it to complete.
Probably because du
Eric Blake wrote:
In particular, the EACCES errors on unlink() mention that without the
sticky bit, all you need is write access to the directory (and your
directory is world writable); with the sticky bit set, you must also own
the directory and file.
^^^
To stave off
--On Wednesday, April 16, 2008 10:36 PM -0500 Brock Noland
[EMAIL PROTECTED] wrote:
Respectfully,
Got it, thanks. The problem I'm having then, I see, is not related to the
coreutils su, but specifically to the BSD su shipped with Darwin. Sorry
for the noise.
Linux:
[EMAIL
Eric Blake wrote:
According to James J. Perry on 4/16/2008 4:25 PM:
| We are in the cutover process and one of the DBAs found this behavior.
| If testfile1 is owned by usera:group1 in a parent directory with
| permissions 777 owned by usera:group1, userb:group2 can delete testfile1
| even if
27 matches
Mail list logo
