Giuseppe Scrivano wrote:
Hi,
I cleaned a bit the Pádraig's example in a new test case.
tests, great!
comments below.
The second patch fixes a problem that I introduced with the commit
e81c4d88c2fce526c02693d539e22c7468dc452b.
I would have posted that patch in the other tail thread.
On
Jim Meyering wrote:
Joel Becker wrote:
On Wed, Jul 29, 2009 at 07:14:37PM +0100, Pádraig Brady wrote:
At the moment we have these linking options:
cp -l, --link #for hardlinks
cp -s, --symbolic-link #for symlinks
So perhaps we should support:
cp --link={soft,hard,cow}
for symlink
Andi Kleen wrote:
Jim Meyering j...@meyering.net writes:
Thanks. I haven't looked, but after reading about the reflink syscall
[http://lwn.net/Articles/332802/] had come to the same conclusion:
this feature belongs with ln rather than with cp.
cp already has -l so it would make sense to
I found another bug I think.
Hopefully the attached is OK, but
I'm not able to compile/test/push at the moment
due to gnulib submodule weirdness.
cheers,
Pádraig.
From 45e2e5f26d4d7641c3ef2bfc3e47aab5bc93b8fe Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com
Jim Meyering wrote:
diff --git a/tests/tail-2/pid b/tests/tail-2/pid
+# Ensure that tail --pid=PID exits successfully when PID is dead.
+# Use an unlikely-to-be-live PID: 2^31-1
+getlimits_
+tail --pid=$INT_MAX -f /dev/null || fail=1
Probably should use $PID_T_MAX
You could speed up the
Joel Becker wrote:
In some sense, using btrfs, nilfs2i, ocfs2 with refcount trees
enabled, or any other CoW-ish filesystem is a tacit approval of the
delayed ENOSPC. The same can be said of thin provisioning LUNs.
However, the other concerns are still valid. A user invoking vanilla
Giuseppe Scrivano wrote:
Hi Pádraig,
thanks for the comments.
Pádraig Brady p...@draigbrady.com writes:
# 300MB seems to be the minimum size for a btrfs with default
parameters.
Actually, it seems the minimum space required is 256MB. Using a 255MB
image I get: device btrfs.img
Giuseppe Scrivano wrote:
Pádraig Brady p...@draigbrady.com writes:
+#expensive_
That comment is just for testing I presume?
Note you can run a single expensive test like:
(cd tests make check TESTS=cp/file-clone VERBOSE=yes
RUN_EXPENSIVE_TESTS=yes)
sorry, yes I commented it out only
Eric Sandeen wrote:
Pádraig Brady wrote:
Eric Sandeen wrote:
TBH I think truncate --allocate sounds a little odd. (Now that I
think back, I think I mentioned this before). truncate(1) and
truncate(2) specifically refer to i_size, which to fs people like me,
has nothing to do
Jim Meyering wrote:
This patch may not be ready for prime time.
I wrote it and the test a few days ago, but haven't
gone back and looked closely. There are just too many
branches and use cases, and I'm sure I haven't considered
all of them. However, all tests do pass, at least on
recent
Tilman Schmidt wrote:
Pádraig Brady schrieb:
I don't see a problem in extending the meaning of the truncate command.
Now truncate isn't the best name for the command but that name
already existed in BSD and so I thought it best to align with that.
So what about also having an fallocate
Eric Sandeen wrote:
Giuseppe Scrivano wrote:
Hello,
Pádraig Brady p...@draigbrady.com writes:
Tilman Schmidt wrote:
...
Why not make it, in the best Unix tradition, a single
executable whose action depends on the name it is run as?
Hmm. Good idea.
There is precedent for that already
Giuseppe Scrivano wrote:
Jim Meyering j...@meyering.net writes:
I am now convinced that cp's new behavior belongs on
a separate option, --reflink (i.e., it should not be the default).
Giuseppe, do you feel like adding that option and adjusting your
test accordingly?
I attached two
Jim Meyering wrote:
+#ifdef POSIX_FADV_DONTNEED
+ off_t off = lseek (STDOUT_FILENO, 0, SEEK_CUR);
+ if (0 = off)
+ignore_value (posix_fadvise (STDOUT_FILENO,
+ off, 0, POSIX_FADV_DONTNEED));
+#endif
That reminds me that it would be nice
Tobia Conforto wrote:
Dear coreutils maintainers,
I'd like to ask for an often needed feature of chmod: the ability to set
different modes for files and directories. I will briefly explain the
need, and then propose a possible syntax.
current: find some/path -type d -exec chmod g+s {} +
Lennart Poettering wrote:
[Second version of the patch, makes this feature optional with --fancy-chars]
--fancy-chars :)
I'm not sure how serious this patch is.
How about:
alias lsf='ls -l --color | sed s/ - / $(tput bold)\u25aa\u25b6$(tput sgr0) /'
cheers,
Pádraig.
p.s. this chunk is far too
Lennart Poettering wrote:
On Tue, 11.08.09 22:27, Pádraig Brady (p...@draigbrady.com) wrote:
this is equivalent I think:
static const char *arrow = - ;
#ifdef HAVE_NL_LANGINFO
if (fancy_chars STREQ (nl_langinfo (CODESET), UTF-8))
arrow = \xe2\x86\x92 ;
#endif
Jim Meyering wrote:
- It's easy to get nearly the same effect with a simple filter,
as Pádraig suggested. (of course, a naive filter fails if
a file name contains - , but the end result is solely for
human consumption, not for mechanical parsing, so that's ok)
Just
Pádraig Brady wrote:
Oh right, so something like:
static const char *arrow;
if (!arrow)
{
if (fancy_chars STREQ (locale_charset(), UTF-8))
arrow = \xe2\x86\x92 ;
else
arrow = - ;
}
DIRED_FPUTS_LITERAL (arrow, stdout);
Note the use of locale_charset
Jim Meyering wrote:
AFAIK, I am the only one who has built the latest snapshot:
http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/17604
Though it's been only two days.
Unless I hear of new bug reports or portability problems soon,
expect coreutils-7.5 to be released in the next
Jim Meyering wrote:
Thanks for the testing and report!
Are these new failures? If they are, it might be worth fixing.
Otherwise, FC5 is so old that I won't worry.
Reverting the symlink timestamp patch make the tests pass
$ wget -q -O- 'http://git.savannah.gnu.org/gitweb/'\
C de-Avillez wrote:
Sorry for the delay, got busy. I just built make check, and got two
errors.
First one is here, I will re-run the second error by itself in a few.
Running on Ubuntu 9.10 (kernel 2.6.31.5 with Ubuntu mods, libc6
2.10.1-0ubuntu6).
FAIL: tail-2/pid
+ tail
Pádraig Brady wrote:
C de-Avillez wrote:
Sorry for the delay, got busy. I just built make check, and got two
errors.
First one is here, I will re-run the second error by itself in a few.
Running on Ubuntu 9.10 (kernel 2.6.31.5 with Ubuntu mods, libc6
2.10.1-0ubuntu6).
FAIL: tail-2/pid
Pádraig Brady wrote:
Jim Meyering wrote:
AFAIK, I am the only one who has built the latest snapshot:
http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/17604
Though it's been only two days.
Unless I hear of new bug reports or portability problems soon,
expect coreutils-7.5
Voelker, Bernhard wrote:
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 ;
Jim Meyering wrote:
Voelker, Bernhard wrote:
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
Voelker, Bernhard wrote:
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
Jim Meyering wrote:
Pádraig Brady wrote:
Subject: [PATCH] tail: fix tail -f failure when inotify used
* src/tail.c (tail_inotify_forever): Use the correct bounds
in the error check of the return from inotify_add_watch().
Reported by C de-Avillez.
---
src/tail.c |2 +-
1 files changed
Jim Meyering wrote:
Pádraig Brady wrote:
These highlighted a couple of issues I think on systems without utimensat().
1. The symlink _target_ gets its time updated
2. If 1 fails then the process returns a failure
I've fixed both in the attached patch hopefully
by only doing the explicit
From 3214858c9b53dcd8d2ef47473427fcd29dc56a7d Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com
Date: Thu, 13 Aug 2009 17:25:09 +0100
Subject: [PATCH] doc: clarify the cp --reflink NEWS
* NEWS: Remove the description associated with the removed
experimental code
Karel Zak wrote:
On Fri, Jul 31, 2009 at 09:27:57PM +0100, Pádraig Brady wrote:
I was thinking the new fallocate util would have the
same options as the existing truncate util.
I.E. -n or -o would not be needed or supportable in all situations.
If you think that users would need those, then I
I've noticed before that coreutils hashing utils
were a little behind in performance, but was prompted
to look at it again when I noticed the recently
updated sha1 implementation in git:
http://git.kernel.org/?p=git/git.git;a=history;f=block-sha1;h=d3121f7;hb=pu
Testing that with the attached
Jim Meyering wrote:
C de-Avillez wrote:
FAIL: tail-2/append-only (exit: 1)
==
...
+ chattr +a f
+ echo x
+ test 1 = 0
+ fail=0
+ sleep 1
+ pid=29813
+ tail --pid=29813 -f f
+ fail=1
What type of file system is that? (i.e., run this: df -hT .)
I
Giuseppe Scrivano wrote:
Hi Pádraig,
I tried to reproduce your results but I wasn't able to do it. The
biggest difference on a 300MB file I noticed was approximately 15% using
on both implementations -O2, and 5% using -O3.
My GCC version is gcc (Debian 4.3.3-14) 4.3.3 and the CPU is:
All tests pass on FC5 and F11.
cheers,
Pádraig.
Voelker, Bernhard wrote:
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;
Prog piR wrote:
date +%^B gives the month in capital letters
but in french august is août, and the accentued letter is not capitalized
date +%^B gives AOûT instead of AOÛT
Nor does tr '[:lower:]' '[:upper:]' support multibyte chars either,
I'll add that to the list of multibyte stuff I
Jim Meyering wrote:
The preserve symlink time stamps feature in coreutils-7.5
is causing trouble in Fedora's build system,
http://thread.gmane.org/gmane.linux.redhat.fedora.devel/119834
because they use a kernel without utimensat support, yet configured/built
coreutils-7.5 in an
Attached is a patch to add a new parameter to the --reflink option,
which will perform a standard copy if COW is not supported.
comments appreciated.
cheers,
Pádraig.
From b1ef11949b95446e6df08ce128d38554715e500b Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com
I think we need to preserve meta data also for cloned files,
as in the attached patch? The patch is mostly indentation changes
and I've copied the only interesting bit below.
cheers,
Pádraig.
diff --git a/NEWS b/NEWS
index c125b31..8b0fdd5 100644
--- a/NEWS
+++ b/NEWS
@@ -8,6 +8,7 @@ GNU
Pádraig Brady wrote:
Attached is a patch to add a new parameter to the --reflink option,
which will perform a standard copy if COW is not supported.
I wonder should we allow --sparse={never,always} with --reflink=auto
as a standard copy could be done in this case? I.E. one could envisage
doing
Should `cp --reflink` unlink() files if the clone fails
rather than leaving zero length files around?
cheers,
Pádraig.
Jim Meyering wrote:
Pádraig Brady wrote:
Should `cp --reflink` unlink() files if the clone fails
rather than leaving zero length files around?
The only argument I can come up with is be consistent with POSIX cp,
which would leave the empty file.
However, I don't feel strongly about
diff --git a/src/stdbuf.c b/src/stdbuf.c
index 5da9341..a3a58e5 100644
--- a/src/stdbuf.c
+++ b/src/stdbuf.c
@@ -108,10 +108,10 @@ Mandatory arguments to long options are mandatory for
short options too.\n\
fputs (HELP_OPTION_DESCRIPTION, stdout);
fputs (VERSION_OPTION_DESCRIPTION,
Nicolas Pitre wrote:
On Sat, 15 Aug 2009, Linus Torvalds wrote:
(Heh. Looking at that, I probably should move the 'size' field first,
since that would have different alignment rules, and the struct would be
more tightly packed that way, and initialize better).
I was about to suggest
Barty Pleydell-Bouverie wrote:
Hi
sort -R fails to randomly sort files. I am using fedora8 - any known reason
for this?
I vaguely remember there being a bug where sort -R was
not working on some locales, but the git history is not
helping me out. Can you retry with `LANG=C sort -R`.
I
Eric Blake wrote:
Subject: [PATCH 2/2] build: avoid unused variable warnings on cygwin
-clone_file (int dest_fd, int src_fd)
+clone_file (int dest_fd ATTRIBUTE_UNUSED, int src_fd ATTRIBUTE_UNUSED)
Minor nit. Would it be better to put (void) dest_fd; (void) src_fd;
in the else clause here as
James R. Van Zandt wrote:
I propose the patch below, which adds the --to option as a synonym for
--destination-directory, to the programs cp, ln, install, and mv.
I think it's easier to remember (and say) something like
mv --to MYDIR myfile hisfile theirfile
While --to
Jim Meyering wrote:
Subject: [PATCH 1/3] tests: cp/reflink-auto guard against a pathological
$TMPDIR
* tests/cp/reflink-auto: Add quotes.
diff --git a/tests/cp/reflink-auto b/tests/cp/reflink-auto
index ff2b1b3..d1f6b2b 100755
--- a/tests/cp/reflink-auto
+++ b/tests/cp/reflink-auto
@@
Ondřej Vašík wrote:
Jim Meyering wrote:
Following up on a long thread from a year ago, here's a patch
to fix the 3.5-year-old readdir-vs-mountpoint-inode bug in ls -i.
Checked on my system and works fine...
It's a shame to have to pessimize ls -i performance, even by this
small amount on
Ondřej Vašík wrote:
Pádraig Brady wrote:
So there was a lot more disk access with the new binary.
but the NEWS suggests that should only be the case for
systems with dysfunctional readdir.
What was your system?
Quite ancient system... I checked this on my old Fedora Core 6...
Anyway
Jim Meyering wrote:
Hi Pádraig,
clang reports this:
timeout.c:330:9: warning: Uninitialized or undefined value returned to
caller.
return status;
^
Even if it really can't happen (which the comment suggests), please
initialize status or ensure that we get a
Jim Meyering wrote:
I've run clang on coreutils, and it spotted quite a few dead stores.
These changes remove them:
The chmod.c change below was not completely transparent, since
the new code returns immediately after issuing the root-dev-inode
warning, whereas the old code would fall
Jim Meyering wrote:
The following patch will be required when coreutils
next updates from gnulib, with gnulib's just-added warn_unused_result
attribute on fts_close.
It eliminates a slight risk that fts_close would fail and these
applications would ignore that failure and exit successfully.
ack
Ondřej Vašík wrote:
Ernest N. Mamikonyan wrote:
[returning mailing list to CC, please keep it there]
On Tue, 01 Sep 2009 02:16:28 -0400, Ondřej Vašík ova...@redhat.com wrote:
Ernest N. Mamikonyan wrote:
Cp(1) doesn't correctly copy extended attributes for read-only files:
touch foo
Follow-up Comment #1, bug #27373 (project coreutils):
I can't reproduce this or see anything wrong with the code.
All 720 of my locales work fine:
$ for LANG in $(locale -a); do printf KnEnMnZn | ./sort -h | tr -d 'n';
echo; done | uniq -c
720 KMEZ
Can you give your libc version?
Could
I had noticed these tests were a little verbose and
had meant to simplify them. Coincidentally today
I triggered a race in tail-2/pid, so the attached
patch kills two birds with the one stone.
cheers,
Pádraig.
From ba37fb2e96334b3cc784a4387d74f726be9be98d Mon Sep 17 00:00:00 2001
From:
Jim Meyering wrote:
Pádraig Brady wrote:
Jim Meyering wrote:
If anyone knows of bug-related fixes that aren't yet applied,
please speak up. I'm thinking of making a snapshot today,
leading to a bug-fix release, coreutils-7.6, next week.
It would be nice to get Ondřej's fix for copy xattrs
A trivial patch make tail --help less confusing to me at least
From: =?utf-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com
Date: Fri, 4 Sep 2009 22:50:15 +0100
Subject: [PATCH] doc: make the tail --sleep-interval help less confusing
* src/tail.c (usage): I read approximately S seconds
as
Ondřej Vašík wrote:
As reported in
http://lists.gnu.org/archive/html/bug-coreutils/2009-08/msg00342.html by
Ernest N. Mamikonyan, cp/mv fails to preserve extended attributes for
read-only source files.
Following patch fixes the issue for me, although maybe it's not perfect
solution. But I
Jim Meyering wrote:
Eric Blake wrote:
According to Pádraig Brady on 9/4/2009 3:57 PM:
A trivial patch make tail --help less confusing to me at least
* src/tail.c (usage): I read approximately S seconds
as approximately 5 seconds for approximately 5 seconds.
Nice commit message! It took me
Jim Meyering wrote:
Pádraig Brady wrote:
Jim Meyering wrote:
worth considering: ---disable-inotify ?
either way is fine with me.
Please adjust the tests not to use double quotes on
the first value, and to use single quotes on the empty string:
Both suggestions are good.
I've updated
Jim Meyering wrote:
I noticed that tail -f didn't work when run via ssh.
I.e., it printed nothing, when I expected it to print the
last 10 lines.
well spotted.
I was wondering about the loop in the test though.
Can the `kill -0` ever fail. Even if that's not redundant
I'm not sure the file is
Jim Meyering wrote:
Here's what I'm testing now:
+for i in $(seq 10); do
+ test -s out break
+ echo sleep .1s
sleep .1
done
Much better, thanks.
BTW, can't we rely on coreutils `test` in tests?
cheers,
Pádraig.
Philip Rowlands wrote:
The conversion of everything to long doubles internally makes seq a lot
slower than it needs to be in integer cases, I assume from the use of
floating-point multiplication for every line of output:
seq.c:257 x = first + i * step;
$ time seq 100
Ondřej Vašík wrote:
Ah, I knew I forgot to do something :). Thanks for spotting this.
Restoring to dest_mode ~omitted_permissions done in attached patch,
dropped redirections from the test as well. Additionally - I modified
the copy.c patch a bit - failure of mode change now doesn't mean
Ondřej Vašík wrote:
Pádraig Brady wrote:
To minimize side affects perhaps we should only do the chmod(600)
if (geteuid () != 0 !access (src_name, W_OK)) ?
Good idea, it would reduce possibility of security leak, playing with
access rights is always a bit dangerous (although here we play
Jim Meyering wrote:
Eric Blake wrote:
According to Jim Meyering on 9/7/2009 3:09 AM:
ls -i now prints consistent inode numbers also for mount points.
This makes ls -i DIR less efficient on systems with dysfunctional readdir,
because ls must stat every file in order to obtain a
Ondřej Vašík wrote:
Pádraig Brady wrote:
Ondřej Vašík wrote:
Pádraig Brady wrote:
To minimize side affects perhaps we should only do the chmod(600)
if (geteuid () != 0 !access (src_name, W_OK)) ?
Good idea, it would reduce possibility of security leak, playing with
access rights is always
Erik Auerswald wrote:
Hi,
On Mon, Sep 07, 2009 at 07:23:12AM -0600, Eric Blake wrote:
According to Michal Svoboda on 9/6/2009 5:33 AM:
When doing cp -va I can see neat quotes (depending on locale), as in
„blah“, but the arrow is still composed of a dash and a greater-than
symbol, as in -.
Philip Rowlands wrote:
On Mon, 7 Sep 2009, Eric Blake wrote:
This was discussed last month. The verdict is no.
http://lists.gnu.org/archive/html/bug-coreutils/2009-08/msg00048.html
This list archive has done strange things with character encodings which
make the discussion difficult to
Pádraig Brady wrote:
Philip Rowlands wrote:
On Mon, 7 Sep 2009, Eric Blake wrote:
This was discussed last month. The verdict is no.
http://lists.gnu.org/archive/html/bug-coreutils/2009-08/msg00048.html
This list archive has done strange things with character encodings which
make
Andreas Schwab wrote:
Pádraig Brady p...@draigbrady.com writes:
# quick dir listing with latest files/dirs at the bottom,
# prettify symlink arrows.
# using eval to precompute the tput sequences.
eval
l() {
ls -lrt --color=always \\...@\ |
sed 's/ - / $(tput bold)▪▶$(tput sgr0
Jim Meyering wrote:
There have been disproportionately many bug fixes since coreutils-7.5.
It's an interesting mix of fixes for recent regressions and for a few older
bugs.
Passed Skipped Failed
\-
Fedora core 5
Jim Meyering wrote:
Hi Pádraig,
On my 6th run of make check, the cat-buf test failed.
It's an inherently racy test.
If the dd process is starved until 2 is printed,
it will end up printing both lines to out.
Hmm. 0.2s was too short between writes so.
I've bumped it up to 0.5s since 0.2
Jim Meyering wrote:
Ulrich Drepper wrote:
Jim Meyering wrote:
Thanks for the report!
Ulrich and Ren reported that the command,
echo foobar | tail -c3 -f
would block indefinitely, while POSIX says that it must not.
This seems to be handled already (see line 1926):
echo foobar |
Eric Blake wrote:
According to Pádraig Brady on 9/7/2009 10:22 AM:
Solaris 9 x86 build failed with:
fstatat.c, line 39: undefined symbol: AT_SYMLINK_NOFOLLOW
Hmm. That should be taken care of by the gnulib fcntl.h replacement.
Are we missing a #include? Can you post the full failure
fsetxattr() is failing for me when the permissions are readonly
but the descriptor is writable as demonstrated by the program below.
I've tried this on ext3 and ext4 with libattr-2.4.43-3.fc11.i586
and linux-2.6.30.5-43.fc11.i586
Is this expected?
cheers,
Pádraig.
#include sys/types.h
#include
Jim Meyering wrote:
Here's another snapshot, prior to coreutils-7.6.
We've inherited quite a few changes from gnulib,
including one to fix the Solaris build failure.
Passed Skipped Failed
\-
Fedora core 5 x86 |
rerunning on local file systems:
Passed Skipped Failed
\-
Fedora core 5 x86 | 348 42 0
Fedora 11 x86 | 343 47 0
Solaris 10 x86| 328 62 0
Eric Blake wrote:
According to OndYej Vaaík on 9/9/2009 2:19 AM:
Hello,
as requested via https://bugzilla.redhat.com/show_bug.cgi?id=511188 , it
would be nice to clarify default blocksize used by du in manpage/--help
output. Although I closed that bugzilla as notabug, further
communication
Christoph Hellwig wrote:
On Tue, Sep 08, 2009 at 12:29:49PM +0100, P??draig Brady wrote:
fsetxattr() is failing for me when the permissions are readonly
but the descriptor is writable as demonstrated by the program below.
I've tried this on ext3 and ext4 with libattr-2.4.43-3.fc11.i586
and
Mike Coleman wrote:
It would be really nice if cut(1) could split fields using whitespace
as a separator (as many other text tools do). Currently I use
$ awk '{ print $3, $4, $5 }'
for this sort of thing, but it seems relatively klutzy, as opposed to (say)
$ cut -w -f 3-5
That
While this patch is more verbose than my previous patch
in this thread, it is more accurate. So let's drop the
previous one. However...
The info was inaccurate for ls, so I've split the SIZE
specific info into a new emit_size_note(). That also
allows refactoring to be done in split and truncate.
Eric Blake wrote:
According to Pádraig Brady on 9/10/2009 6:29 AM:
While this patch is more verbose than my previous patch
in this thread, it is more accurate. So let's drop the
previous one.
+ printf (_(\n\
+If none of the environment variables BLOCKSIZE, BLOCK_SIZE
Jim Meyering wrote:
Here's one more posssible wording:
Display values are in units of the first available SIZE from --block-size,
and the %s_BLOCK_SIZE, BLOCK_SIZE and BLOCKSIZE environment variables.
Otherwise, it defaults to 1024 bytes (or 512 bytes if POSIXLY_CORRECT is set).
Pushed with
Jim Meyering wrote:
Pádraig Brady wrote:
rerunning on local file systems:
Passed Skipped Failed
\-
Fedora core 5 x86 | 348 42 0
Fedora 11 x86 | 343 47 0
Michael Stone wrote:
I'm attaching the current patches from the debian coreutils package to
make sure they don't get missed.
61_whoips: this one will be problematic to include directly as I don't
have the autoconf-fu to make the network functions portable to non-linux
platforms, and the core
Roger McNichols wrote:
Currently using version 5.2.1 of coreutils 'split' command produces files
with 'intelligent' suffixes. That is, the number of letters (or digits)
required
is based on the known number of output files that will be required.
Actually coreutils does not employ
Eric Blake wrote:
According to Roger McNichols on 9/11/2009 6:51 PM:
Currently using version 5.2.1 of coreutils 'split' command produces files
with 'intelligent' suffixes. That is, the number of letters (or digits)
required
is based on the known number of output files that will be
Bert Wesarg wrote:
This short mail is only to inform you, that the dd/skip-seek-past-file
test fail on a ecryptfs mount. Because this commands takes a long time
and eat my hard disk space:
truncate --size=$OFF_T_MAX in
More infos at monday.
So ecryptfs doesn't allow sparse files:
Jim Meyering wrote:
Hi Pádraig,
Is this ok with you?
-If the command times out, then we exit with status 124,\n\
-otherwise the normal exit status of the command is returned.\n\
-If no signal is specified, the TERM signal is sent. The TERM signal\n\
-will kill processes which do not catch
Bert Wesarg wrote:
2009/9/14 Pádraig Brady p...@draigbrady.com:
Bert Wesarg wrote:
This short mail is only to inform you, that the dd/skip-seek-past-file
test fail on a ecryptfs mount. Because this commands takes a long time
and eat my hard disk space:
truncate --size=$OFF_T_MAX in
More
Roger McNichols wrote:
Thanks for the feedback.
Do you mean select the appropriate suffix length based on size,
or do you mean the zzaa, zzab scheme? The former wouldn't
help when processing a pipe for example so I'd probably
stick with the latter method for consistency.
Currently,
Jim Meyering wrote:
Pádraig Brady wrote:
:( So ecryptfs reports 0 disk usage even though it's
writing out the files and using up space in the file system.
IMHO, that's a serious bug, and we should not change the
tests to work around it.
It is serious enough that I'm inclined not even
Jim Meyering wrote:
Hi Pádraig,
Is this ok with you?
In the same vein, how about this cleanup?
From 23f8cfda81a7261edeebe406582bb68d643f10ca Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com
Date: Thu, 10 Sep 2009 08:00:31 +0100
Subject: [PATCH] doc: ls:
Roger McNichols wrote:
I found a machine with the old version of split.
home:~ uname -a
Linux home 2.2.13 #4 Thu May 8 23:11:31 CDT 2003 i686 unknown
home:~
home:~ split --version
split (GNU textutils) 1.22
home:~
Here's the result of
home:~ cat /var/log/messages | split -2 -
I was trying to disable the green colors today in my ls listing
and noticed that if you do that the directories are shown
without color rather than falling back to the standard color
for directories (blue).
The attached patch fixes that up.
cheers,
Pádraig.
From
Pádraig Brady wrote:
Roger McNichols wrote:
I found a machine with the old version of split.
home:~ uname -a
Linux home 2.2.13 #4 Thu May 8 23:11:31 CDT 2003 i686 unknown
home:~
home:~ split --version
split (GNU textutils) 1.22
home:~
Here's the result of
home:~ cat /var/log/messages
501 - 600 of 3092 matches
Mail list logo
