Mike Frysinger wrote:
this is because many distros patch coreutils' uname to return
something useful on Linux. the GNU version relies on the standard
interfaces to do that (which they don't).
you can find the patch i've been keeping up-to-date in Gentoo:
Andrew Warshall wrote: (Sunday, November 04, 2012 8:21 PM)
make[7]: *** No rule to make target `tests/chown/basic.sh.log',
needed by `test-suite.log'. Stop.
Is anyone else having our problem?
In particular, is it local to GNU make 3.82?
well, not the same, but ...
make check-TESTS
Andrew Warshall wrote (Monday, November 05, 2012 3:30 PM):
This is on OpenSuSE 12.2 with GNU make 3.82.
I'd be curious to know what it's supposed to be doing. For example,
should make check-root be running any gnulib-tests at all? Those
should all get run by make check anyway, no?
not sure.
David Diggles wrote (Friday, September 28, 2012 4:45 AM)
DESCRIPTION
Run COMMAND with an adjusted niceness, which affects process
scheduling. With no COMMAND, print the current niceness. Nicenesses
range from -20
(most favorable scheduling) to 19 (least favorable).
Craig Sanders wrote:
seq only supports floating point types like f and g in the --format string.
Other types, including i,d,o,u,x,X would also be useful.
e.g. seq --format 'prefix%02isuffix' 1 50 to print zero-padded 1-50 with
user-specified prefix and suffix strings.
IMO custom format
Bob Proulx wrote (Monday, September 03, 2012 9:51 AM)
Jim Meyering wrote:
Could you be thinking of some other rm?
Coreutils' rm has rejected that for a long time:
...
POSIX requires rm to reject any attempt to delete an explicitly specified
. or .. argument (or any argument whose last
Andreas Schwab wrote:
[...] read the second paragraph:
If either of the files dot or dot-dot are specified as the basename
portion of an operand (that is, the final pathname component) or if
an operand resolves to the root directory, rm shall write a
diagnostic message to
Jim Meyering wrote (Thursday, August 02, 2012 2:08 PM):
You need the double quotes around $nl with bash,
but not with zsh:
zsh$ nl='
quote '
zsh$ printf %s $nl
zsh$
For bash, one solution is:
$ printf '\na\nb'|tac -rs '.\|'$(printf \n)
b
Jim Meyering wrote:
That has prompted a nicely animated debate ;-)
... and it goes on ;-)
What about these?
find . -name '*.c' | xargs grep -F '0, };'
./src/ls.c:mbstate_t mbstate = { 0, };
./src/shred.c: struct Options flags = { 0, };
./src/tr.c: bool in_set[N_CHARS] =
Anoop Sharma wrote:
Head command does not position file pointer correctly for negative line
count. Here is a demonstration of the problem.
The problem doesn't seem to be limited to negative
line counts. I replaced the 10 ABC lines by a number
sequence to demonstrate this issue clearer.
$
Jim Meyering wrote:
I tried to use the su from coreutils (with or without your patch)
and found that it does not work when it attempts to authenticate.
E.g., it cannot su to any user on this Fedora 17 system. If su
remains so broken that it does not work out-of-the-box on F17,
then it's not
Rocky Bernstein wrote:
So perhaps for the delays, you or someone reading could make the stylistic
changes that would take, what, maybe a few minutes?
IMHO no.
As Jim is the CU maintainer, he (or Padraig or someone else) will push
changes to git. As it's always good to have someone else to
Jim Meyering wrote:
jaalto wrote:
| -r, --reverse
|
| $ df -Hlr
|
| Size Used Avail Use% Mounted-on Filesystem
| 6.0G 4.1G 1.7G 72% / rootfs
| 192M 0 192M 0% /dev udev
| 40M 1.5M 38M 4% /run tmpfs
|
George R Goffe wrote:
This tactic would fail if there was no partition mounted but the specific
mount point was the culprit like when a user gets root (not uncommon in
the environments I work in) and goofs by copying data to a mount point but
has NOT mounted a partition first.
There's no way
Jim Meyering wrote:
Davide Brini wrote:
...
At least in bash, but I suppose in other shells too,
rm -rf #*
treats the #* part as a comment, and (if you remove the -f) complains
about missing operand to rm.
That is the default, but for an interactive shell,
that behavior can be
Jim Meyering wrote:
Voelker, Bernhard wrote:
I think Davide's point is not about the # comment ... rm won't see
that on argv anyway. The point is that 'rm -f' does not complain about
missing operands while 'rm' does:
$ rm
rm: missing operand
Try `rm --help' for more
tags 10819 fixed
thanks
Jim Meyering wrote:
Voelker, Bernhard wrote:
Good point.
That means, the info page could be enhanced to mention that
special case (see below).
...
Subject: [PATCH] doc: document 'rm -f' better
Thanks. I've applied that with these tweaks:
Even better, thank
Jim Meyering wrote:
I see that Fedora still uses su from coreutils, too,
so this is a worthwhile change.
So does OpenSuSE.
As in coreutils.texi, -l and -p can be used together,
although it's not very clear what will happen:
@item -m
@itemx -p
@itemx --preserve-environment
...
Parts
Elliott Forney wrote:
The intent of the POSIX spec is that files should be counted only once,
regardless of whether they are arrived at via hard links, or by following
symbolic links with -L, or by any other means.
I agree that symlinks and hard links and maybe even bind mounts or
Bob Proulx wrote:
Alan Curry wrote:
Why not let the -c total be correct *and* the -s individual numbers also be
correct for the names they are next to? Like this:
$ mkdir a b ; echo hello a/a ; ln a/a b/b ; du -cs a b
8 a
8 b
12 total
The fact that the
Jim Meyering wrote:
Pádraig Brady wrote:
...
I thought a little about this today.
Nice description of the issues.
BTW: there was a discussion recently about the
fallocate utility of util-linux, e.g.
http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/5045
Maybe looking into
Paul Eggert wrote:
+ -n, --no-dereferencetreat LINK_NAME as a normal file if\n\
+it is a symbolic link to a directory\n\
IMHO that's wrong.
ln also creates a hardlink of a symlink if that points to a file:
$ touch f
$ ln -s f flink
$ ln -n flink
Pádraig Brady wrote:
I reproduced this weirdness in OpenSuse 10.3 in a VM.
Much less frequently though.
Delays in 10 out of 2750
Signal handler call failure in 1 out of 2750
Sorry for my late reply. Thanks.
The delays might be due to bash, but I updated
to 4.2 and the issue still
Eric Blake wrote:
On 10/24/2011 02:06 AM, francky.l...@telenet.be wrote:
Hello Eric,
This is a sequence which reproduces my situation.
rm -rf ?
mkdir -p a b/a
touch b/a/file1 a/file2
mv a b
mv: cannot move `a' to `b/a': Directory not empty
Thanks for your formula. In fact,
Jim Meyering wrote:
Eric Blake wrote:
...
As currently coded in the grammar, this is correct. But if someone
were willing to put forth the effort to update parsedate.y, as well as
enhance the testsuite to cover things, it might be possible to improve
the grammar to accept both common
reopen 9737
thanks
Pádraig Brady wrote:
Bah, this is just a racy test I think.
Hopefully the attached fixes it.
Thank you for the patch.
I tried it 16 times:
* 14x PASS, execution time real 0.4s
* 1x test failure (in the 5th run)
* 1x the test lasted 20s (in the 16th run)
... which
Pádraig Brady wrote:
On 10/13/2011 04:58 PM, Voelker, Bernhard wrote:
reopen 9737
thanks
Pádraig Brady wrote:
Bah, this is just a racy test I think.
Hopefully the attached fixes it.
Thank you for the patch.
I tried it 16 times:
* 14x PASS, execution time real 0.4s
* 1x test
I don't wanna ruin your day (by reporting on 0-day old 8.14), but ...
On a virtual SLES 10.3 system with 2 Xeons (E5420 @ 2.50GHz),
the above test failed - but just once.
I cannot reproduce the error. I tried ~30 times, once with low system
load and once with a load of about 10.
Fortunately, I
Bryan Lee wrote:
The term third wednesday seems to be evaluating incorrectly.
glaive 12:24:56 [~]% date
Mon Oct 10 12:24:59 EDT 2011
glaive 12:24:59 [~]% date -d first wednesday
Wed Oct 12 00:00:00 EDT 2011
glaive 12:25:09 [~]% date -d second wednesday
Wed Oct 12 00:00:01 EDT 2011
Eli the Beareded wrote:
$ tail -f -1 some.log
tail: option used in invalid context -- 1
$
I think you wanted this:
$ tail -f -n1 some.log
The syntax is explained quite nice in recent versions:
-n, --lines=Koutput the last K lines, instead of the last 10;
Paul Eggert wrote:
diff --git a/m4/extensions.m4 b/m4/extensions.m4
index 1330503..22156e0 100644
--- a/m4/extensions.m4
+++ b/m4/extensions.m4
@@ -1,4 +1,4 @@
-# serial 9 -*- Autoconf -*-
+# serial 10 -*- Autoconf -*-
# Enable extensions on systems that normally disable them.
#
Pádraig Brady wrote:
On 13/07/11 14:11, Eric Blake wrote:
On 07/13/2011 03:05 AM, Pádraig Brady wrote:
On 13/07/11 08:55, Joachim Schmitz wrote:
I found this in mktemp.c, line344 (well, my compiler found it for me and
warned about 'possible use of = where == was intended'):
if
Jim Meyering wrote:
Ludwig Nussel wrote:
Jim Meyering wrote:
- tests would be most welcome, but I won't insist on those
Hmm, I'm not sure that's feasible. Tests would need to run as
root and they'd likely have to modify /etc/pam.d.
root-only tests are not a problem.
There are already
Jim Meyering wrote:
James Youngman wrote:
One tweak: use date -d 12:00 +1 day instead of date -d tomorrow in
the example.
Good idea. That makes it immune to failure in a one hour interval
on the day before the spring DST transition.
hmm, shouldn't the tomorrow handling be fixed then?
--
Jim Meyering wrote:
Voelker, Bernhard wrote:
Jim Meyering wrote:
James Youngman wrote:
One tweak: use date -d 12:00 +1 day instead of date -d tomorrow in
the example.
Good idea. That makes it immune to failure in a one hour interval
on the day before the spring DST transition.
hmm
Jim Meyering wrote:
Voelker, Bernhard wrote:
Jim Meyering wrote:
Voelker, Bernhard wrote:
Jim Meyering wrote:
James Youngman wrote:
One tweak: use date -d 12:00 +1 day instead of date -d tomorrow in
the example.
Good idea. That makes it immune to failure in a one hour interval
Jim Meyering wrote:
Voelker, Bernhard wrote:
...
We can't change the fact that the spring DST transition
introduces a one-hour hole containing invalid times.
Whenever we tell date to use a time in such a hole,
date must diagnose it as invalid.
`date` is still a tool, so I feel it should
Bob Proulx wrote:
I generally dislike combining the functionality of several different
commands into one command. In this case combining mkdir and chmod and
I don't see any reason they can't be used individually. Plus mkdir
already allows you to create directories with a specified
Hi *,
building coreutils-8.12 with '--enable-gcc-warnings' fails on my SLES 10.3
server:
CC uinttostr.o
cc1: warnings being treated as errors
In file included from uinttostr.c:3:
anytostr.c: In function 'uinttostr':
anytostr.c:39: warning: comparison of unsigned expression 0 is always
Hi Syed,
this is most likely not a bug in the GNU coreutils.
I bet you copied mmencode from your UNIX workstation
to your Linux PC ... which has a different platform
(maybe an Intel CPU?):
$ file mmencode
mmencode: PA-RISC2.0 shared executable dynamically linked - not stripped
Have a nice
Running `df -B...` with a SIZE which is greater than the total disk space
returns the same value in the 'Used' and 'Available' column - see example
below with T, P and E:
$ for f in 1 K M G T P E Z Y ; do ( set -x df -B$f . ) ; done
+ df -B1 .
Filesystem 1B-blocks Used Available
Paul Eggert wrote:
On 03/22/2011 08:47 AM, Voelker, Bernhard wrote:
BTW: why are `Z' and `Y' too large?
They don't fit in 64 bits.
wow, I wasn't aware that there are already 128-bit systems!
Bye,
Berny
Jim Meyering wrote:
That's an artifact of GNU sleep using strtod, which means inf and
INFINITY are also accepted:
$ timeout 1 sleep inf
[Exit 124]
what's wrong with `sleep inf`?
Have a nice day,
Berny
Jim Meyering wrote:
src/csplit: 2GiB of spacesxx2GiB of 0's: File name too long
I'm not an expert at all in this, but isn't there PATH_MAX on every system?
So the suffix format could be limited to `csplit -b %PATH_MAXd`.
Just a thought...
--
Have a nice day,
Berny
Jim Meyering wrote:
It is a deliberate feature.
Personally, I prefer the semantics of 'mv -f --backup=numbered'
so use a shell alias.
just for fun I tried to get no backup created and tried '--backup=never',
but a backup is still created (version 8.5 on Cygwin, and 5.93 on SLES-10.3):
$
On 08/23/2010 18:02, Payk Eggert wrote:
... For example:
$ TZ=Pacific/Kwajalein date -d 1993-08-20
date: invalid date `1993-08-20'
There was no time during the day 1993-08-20, because at midnight Kwajalein
moved the clocks ahead by 24 hours.
BTW: This example looks different here:
$
On 08/24/10 10:04, Eggert, Paul wrote:
On 08/24/10 00:23, Voelker, Bernhard wrote:
BTW: This example looks different here:
$ TZ=Pacific/Kwajalein date -d 1993-08-20
Sat Aug 21 00:00:00 MHT 1993
$ date --version
date (GNU coreutils) 8.5
Packaged by Cygwin (8.5-2
On 08/24/2010 15:09, Eric Blake wrote:
On 08/24/2010 01:23 AM, Voelker, Bernhard wrote:
$ TZ=Pacific/Kwajalein date -d 1993-08-20
Sat Aug 21 00:00:00 MHT 1993
$ date --version
date (GNU coreutils) 8.5
Packaged by Cygwin (8.5-2)
Why?
Most likely, because cygwin is using
Pádraig Brady wrote:
Jim Meyering wrote:
what about --ref=non-regular-file ?
Yes that's safer. st_size is only defined for regular files
(or shared mem), so I'll only allow regular files.
I'll push a separate patch soon.
what about --ref=- ?
one wants to have a file with the size
of a
Bob Proulx wrote:
sandy bas wrote:
Comma delimited files often have fields of the form big,black,bear
where the commas within the quotes are not delimiters. A useful
option in cut would be to ignore the commas (delimiters) within the
quotation marks.
I would be glad to put it in if you
Peng Yu wrote:
I agree with you that this is may not be possible for whole file
system. But under the assumptions that symbolic links and their
targets are always in a number of directories (user configurable) on
the same file system, then it is doable. This is practically what I
need.
you
Peng Yu wrote:
On Mon, May 10, 2010 at 4:37 AM, Voelker, Bernhard wrote:
you need a reference to the actual inode, don't you?
So what a about using hardlinks?
Harlinks do not work across filesystems. I think that it is better
stick with symbolic links.
you are right, of course.
You'll have
Pádraig Brady wrote:
cp now accepts the --attributes-only option to not copy file data,
which is useful for efficiently modifying files.
is this like `touch -r ...`?
Bye,
Berny
Pádraig Brady wrote:
On 14/04/10 17:27, Voelker, Bernhard wrote:
Pádraig Brady wrote:
cp now accepts the --attributes-only option to not copy file data,
which is useful for efficiently modifying files.
is this like `touch -r ...`?
Right, except that it handles
permissions and xattrs
Eric Blake wrote:
Note that if you use rm to remove a file, it might be possible to
recover the contents of that file, given sufficient expertise and/or
time. If you want more assurance that the contents are truly
unrecoverable, consider using shred.
+1
Have a nice day,
Berny
Pádraig Brady wrote:
On 10/03/10 13:46, Reuben Thomas wrote:
rm(1) says, quite correctly:
Note that if you use rm to remove a file, it is usually possible to
recover the contents of that file.
How about just doing: s/is usually/might be/
what about adding a hint to `shred`?
Have a
On 3/1/2010 5:58 PM, Eric Blake wrote:
According to Igor Zakharoff on 3/1/2010 9:49 AM:
$ echo -e ru.unix /h\nru.unix.ftn /h\nru.unix.prog /h | sort
I somehow get
ru.unix.ftn /h
ru.unix /h
ru.unix.prog /h
Is it a bug?
Nope. I reproduced your results with the en_US locale, but not
Eric Blake wrote:
According to Voelker, Bernhard on 3/2/2010 1:34 AM:
I understand that the sort order depends on the locale, i.e. LC_ALL,
but this doesn't explain the differences I get on Solaris 5.10, SLES 10.1,
and Cygwin (given that sort didn't change about this point in the past
On 2/22/2010 01:56 PM, Eric Blake wrote:
According to SANTHOSH on 2/22/2010 12:06 AM:
I am Useing Red Hat Enterprise Linux AS release 4. SUDANLY I USED \rm
-r command in my pc i was losed my imartent files
sir any chance to retrev that file Please Help me
Sorry, but you've just learned a
Eric Blake wrote:
But the point remains - such helps can only be enabled via an extension
(since they change the POSIX-specified behavior), and thus do no good if a
user does not request that extension.
ok, I agree.
Thanks.
Eric Blake wrote:
According to Voelker, Bernhard on 2/18/2010 8:31 AM:
-error (EXPR_INVALID, 0, _(non-numeric argument));
+error (EXPR_INVALID, 0, _(non-integer argument));
Maybe a dumb question:
Why's the error message hardcoded?
It isn't.
Isn't
Eric Blake wrote:
-error (EXPR_INVALID, 0, _(non-numeric argument));
+error (EXPR_INVALID, 0, _(non-integer argument));
...
-error (EXPR_INVALID, 0, _(non-numeric argument));
+error (EXPR_INVALID, 0, _(non-integer argument));
Maybe a dumb
Peng Yu wrote:
Suppose I have directory a and b, the following command will copy the
content of a to b/a, rather than overwrite the directory 'b' by the
directory 'a'. I'm wondering if there is an option to overwrite 'b'?
cp -r a b
you mean something like this?
cp -r a/. b
Have a look
Jim Meyering wrote:
Voelker, Bernhard wrote:
$3 = {d_ino= 289015472,
d_off= 4096,
d_reclen = 24,
d_type = 0 '\0',
d_name = s, '\0' repears 254 times}
Thanks. That confirms what I suspected:
your system's readdir sets d_type for directories
Eric Blake wrote:
According to Voelker, Bernhard on 1/8/2010 7:40 AM:
Hello,
`make check` failed for 2 of 357 tests here:
openSUSE 10.3 (X86-64) (inside a 11 hosted virtual machine)
kernel 2.6.9-023stab051.3-smp
gcc 4.2.1
CPU: Quad-Core AMD Opteron(tm) Processor 2352
Which
Jim Meyering wrote:
Volker, you can diagnose this by stepping through ls.c's print_dir
function, doing print *next for each entry.
see attached.
One of those three will be the entry for d/s (others are usually
. and ..) and we care about the direct.d_type member.
Strangely, I got one for
Hello,
`make check` failed for 2 of 357 tests here:
openSUSE 10.3 (X86-64) (inside a 11 hosted virtual machine)
kernel 2.6.9-023stab051.3-smp
gcc 4.2.1
CPU: Quad-Core AMD Opteron(tm) Processor 2352
FAIL: ls/stat-dtype (exit: 1)
=
+ ls --version
ls (GNU
Jim Meyering wrote:
Daniel Borkmann wrote:
I think it would rather fit into the coreutils than having it's own
distribution package. What do you think? (Source attached)
...
Thanks for the suggestion, but it seems better to
do that with some shell and perl:
regardless if it's written in C,
Jim Meyering wrote:
Voelker, Bernhard wrote:
building coreutils-8.0 fails on Solaris 10:
Undefined first referenced
symbol in file
eaccess ../lib/libcoreutils.a(euidaccess.o)
The symbol is needed
Jim Meyering wrote:
Voelker, Bernhard wrote:
Jim Meyering wrote:
Voelker, Bernhard wrote:
I'm wondering why there are so many tests (in coreutils-8.0( run by
sudo env PATH=$PATH NON_ROOT_USERNAME=$USER make -k check-root
which are skipped with must be run as non-root
Jim Meyering wrote:
Voelker, Bernhard wrote:
Jim Meyering wrote:
Voelker, Bernhard wrote:
Jim Meyering wrote:
Voelker, Bernhard wrote:
I'm wondering why there are so many tests (in coreutils-8.0( run by
sudo env PATH=$PATH NON_ROOT_USERNAME=$USER make -k check-root
Jim Meyering wrote:
Voelker, Bernhard wrote:
I'm wondering why there are so many tests (in coreutils-8.0( run by
sudo env PATH=$PATH NON_ROOT_USERNAME=$USER make -k check-root
which are skipped with must be run as non-root,
e.g. touch/read-only, mv/perm-1, etc
Eric Blake wrote:
+if test -w /dev/full test -c /dev/full; then
just a side note:
/dev/full seems to be broken on some (old?) kernels:
$ ls -l /dev/full
crw--w--w- 1 root root 1, 7 2009-08-17 09:55 /dev/full
$ uname -a
Linux linx2 2.6.16.60-0.23-smp #1 SMP Thu May 15 06:38:31 UTC 2008
Pádraig Brady wrote:
Voelker, Bernhard wrote:
Eric Blake wrote:
+if test -w /dev/full test -c /dev/full; then
just a side note:
/dev/full seems to be broken on some (old?) kernels:
$ ls -l /dev/full
crw--w--w- 1 root root 1, 7 2009-08-17 09:55 /dev/full
$ uname
Hi,
building coreutils-8.0 fails on Solaris 10:
Undefined first referenced
symbol in file
eaccess ../lib/libcoreutils.a(euidaccess.o)
The symbol is needed for these utils (aren't this almost all?):
uname,
Hi,
I'm wondering why there are so many tests (in coreutils-8.0( run by
sudo env PATH=$PATH NON_ROOT_USERNAME=$USER make -k check-root
which are skipped with must be run as non-root,
e.g. touch/read-only, mv/perm-1, etc.
Is that on purpose (to check wether the root check works;-) ?
Hi,
(sorry for the noise again, but I hope this will help others sometimes later.)
this root test failed on my Solaris 10 box, built with a non-GNU compiler:
$ cc -V
cc: Forte Developer 7 C 5.4 2002/03/09
$ NON_ROOT_USERNAME=ecs2 gmake check TESTS=cp/preserve-gid VERBOSE=yes
The output
Jim Meyering wrote:
Pádraig Brady wrote:
(mkdir t cd t seq 100 | xargs touch)
(find t t t t -type f | xargs -n100 -P4 md5sum) \
| sed -n '/[0-9a-f]\{32\} /!p' | grep . /dev/null fail=1
Odd... that doesn't fail on any of the systems where I tried it:
rawhide, fedora 11, debian
Jim Meyering wrote
I'm beginning to think there's a fundamental problem with your system.
Here's the comparable part of truss output on a working Solaris 10
system:
...
Remember, you did not compile with gcc.
Unless someone can suggest an alternative explanation,
I'll have to assume this is
Jim Meyering wrote:
I suspect this patch works around your compiler's
inadequate bool support:
diff --git a/src/install.c b/src/install.c
index 73b3981..19efb1d 100644
--- a/src/install.c
+++ b/src/install.c
@@ -189,7 +189,7 @@ static bool
extra_mode (mode_t input)
{
const mode_t
all non-root tests have successfully now, but one of the root-tests
failed:
===
GNU coreutils 7.4.127-d2510: tests/test-suite.log
===
1 of 1 test failed.
.. contents:: :depth: 2
Voelker, Bernhard wrote:
all non-root tests have successfully now, but one of the root-tests
failed:
===
GNU coreutils 7.4.127-d2510: tests/test-suite.log
===
1 of 1 test failed
Jim Meyering wrote:
Please run this command from your build directory
cd src { touch a b; mode3=2755; ./ginstall -Cv -m$mode3 a b }
and tell us what it prints.
somehow, my shell (/bin/ksh) doesn't like the { ... } syntax here:
$ cd src { touch a b; mode3=2755; ./ginstall -Cv -m$mode3
Jim Meyering wrote:
sudo env PATH=$PATH NON_ROOT_USERNAME=$USER make -C tests \
TESTS=cp/preserve-gid VERBOSE=yes
I think you meant
sudo env PATH=$PATH NON_ROOT_USERNAME=$USER make -C tests check \
TESTS=cp/preserve-gid VERBOSE=yes
BTW: I'm not sure but shouldn't the tests make
Jim Meyering wrote:
Long-term, best for you would be to install GNU diffutils.
done:
===
GNU coreutils 7.4.127-d2510: tests/test-suite.log
===
1 of 1 test failed.
.. contents::
Jim Meyering wrote:
The *second* time that command is run, it appears to print nothing.
Do this in src/:
./touch a b; mode3=2755
./ginstall -Cv -m$mode3 a b
./ginstall -Cv -m$mode3 a b
Bingo!
If the second invocation of ginstall doesn't print anything,
that indicates a
make failed for me:
- non-root
- Solaris 10:
$ uname -a
SunOS avanti 5.10 Generic_127111-08 sun4u sparc SUNW,SPARC-Enterprise
- Compiler:
$ cc -V
cc: Forte Developer 7 C 5.4 2002/03/09
- ./configure --prefix=/user/ecs2 --disable-nls
- Make output snippet:
CC sort.o
sort.c, line
Jim Meyering wrote:
coreutils began the switch to C99 years ago, and that sort of
initialization is a new addition. We did debate whether to use the
new-to-coreutils construct. However, if that's the only bit of code
that causes build failure for this compiler, I may accommodate it with
the
Jim Meyering wrote:
Here's a better patch.
(this also renames check-AUTHORS to sc_check-AUTHORS)
this doesn't work - stdbuf is still tried to be built.
I double-checked with a fresh `tar zxf ...` and the patches
to the 3 files.
I attached the (solaris) diff of the files and the
output of `make
Jim Meyering wrote:
Here's a tarball with those two not-yet-pushed changes:
Now, `make check` works ... mostly.
I attached the 2 logfiles - 1 run as root, 1 run as non-root.
It seems that the test-suite sometimes relies on GNU coreutils
like rm or mv in the path instead of the fresh compiled
Jim Meyering wrote:
Voelker, Bernhard wrote:
FAIL: misc/stdbuf (exit: 1)
That one's easy.
My fault for using skip_test_ before it's defined:
It works:
./misc/stdbuf: skipping test: stdbuf not built
SKIP: misc/stdbuf
FAIL: install/install-C (exit: 1
Jim Meyering wrote:
Did you run it as recommended in README, i.e.,
after building as non-root, run this:
sudo env PATH=$PATH NON_ROOT_USERNAME=$USER make -k check-root
no.
I built it as non-root, ran `make check` as non-root, and then
- because I saw that a few tests can only be run as
Pádraig wrote:
What is your exact dd command please, and destination file system.
I was running KNOPPIX 5.3.1; the source was a harddisk partition, and
the target was a file in an ext2 filesystem on a harddisk in an USB device
mounted on /media/sdb2/:
$ dd if=/dev/sda5
Pádraig wrote:
Yep I think so. Moving just the install_signal_handlers() to the top,
can we expect this to happen in one of the next releases?
p.s. I'm still unsure as to why open(O_TRUNC) takes a while.
Perhaps there is a trunc=paranoid mount option I'm unaware of
that actually writes zeros
Hi *,
short question:
is there a particular reason why the signal handlers are installed after
ftruncate() in dd?
Long story:
I ran dd for a new backup of my 150GB partition to an external USB drive while
I started
while kill -USR1 pid ; do sleep 30 ; done
in a separate terminal. The
95 matches
Mail list logo
