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
* tests/mkdir/selinux: Skip the mknod test if it's a built-in.
diff --git a/tests/mkdir/selin
-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 w
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
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
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-autoc
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:
>> |
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
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 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 required to e
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 @@
conti
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 sensitiv
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 t
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, but
[ 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) : 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 t
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 permis
-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 del
-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 is
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 confusion.
[EMAIL PROTECTED] build]# su -l zimbra
[EMAIL PROTECTED] ~]$ echo $PATH
/opt/zimbra/bin:/opt/zimbra/zimbramon:/opt/zimbra/postfix/sbin:/opt/zimbra/openldap/bin:/opt/zimbra/snmp/bin:/opt/zimbra/sleepycat/bin:/opt/zimbra/openssl/bin:/opt/zimbra/java/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin
On Wed, Apr 16, 2008 at 9:55 PM, Quanah Gibson-Mount <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] build]# su -l zimbra -c "echo $PATH"
> /usr/kerberos/sbin:/usr/local/java/bin:/usr/local/ant/bin:/usr/local/mysql/bin:/usr/local/ant/bin:/usr/local/java/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/us
--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 PROTECTE
On Wed, Apr 16, 2008 at 7:01 PM, Pádraig Brady <[EMAIL PROTECTED]> wrote:
> 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 sour
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
rh <[EMAIL PROTECTED]> wrote:
> 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.
If you have an old version, and depending on how it's configured,
ext3 can be
On Wed, Apr 16, 2008 at 11:30 PM, Brock Noland <[EMAIL PROTECTED]> wrote:
> I agree that I would expect if the file is seekable and seek fails, dd
> would exit. But here it looks like we just cannot seek that large of
> an offset?
I implemented something that seeks in portions and it results
Pádraig Brady <[EMAIL PROTECTED]> wrote:
> 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 POS
34 matches
Mail list logo
