Hi Bernhard,
Bernhard Voelker writes:
> Thanks for the patch.
>
> What is the use case? I mean, if one wants only the numeric numbers,
> then this is usually in a script for automatic processing, and then
> I thinks it's clearer to have uid and group/groups separated:
>
> $ id -u
> 1000
>
>
Hi,
there are cases where I'd like to see only the numeric values in the
`id` output.
I could get this information separately, but having a new option
and just one command simplifies the task.
Are you fine with a change like the following?
If you have nothing against it, I will clean it up and
Pádraig Brady writes:
> The attached should make things more efficient here.
>
> thanks,
> Pádraig.
>
>
> From 7959bbf19307705e98f08cfa32a9dcf67672590c Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?P=C3=A1draig=20Brady?=
> Date: Mon, 9 Mar 2015 19:27:32 +
> Subject: [PATCH] yes: output data mor
Pádraig Brady writes:
> thanks!
> Pádraig.
Thanks for the review, I've amended the changes you suggested:
>From b2babc9838b52892e2cdc46bc4590fa852daa0eb Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Sun, 25 Jan 2015 01:33:45 +0100
Subject: [PATCH] sync: add suppo
Pádraig Brady writes:
> On 26/01/15 08:36, Giuseppe Scrivano wrote:
>> Pádraig Brady writes:
>>
>>> On 25/01/15 18:05, Bernhard Voelker wrote:
>>>> On 01/25/2015 06:41 PM, Pádraig Brady wrote:
>>>>> So we have: fdatasync < fsync <
Pádraig Brady writes:
> On 25/01/15 18:05, Bernhard Voelker wrote:
>> On 01/25/2015 06:41 PM, Pádraig Brady wrote:
>>> So we have: fdatasync < fsync < syncfs < sync
>>> referring to:: file data, file data + metadata, file system, all file
>>> systems
>>
>>> [...]
>>
>>> I'd be incline to go wi
Paul Eggert writes:
> If we're adding this sort of option, shouldn't we also give users the
> ability to invoke fsync and fdatasync on a single file, as opposed to
> syncfs on an entire file system?
Good point. Should we instead add something like --file-system and
--data-only, respectively for
* configure.ac: Check if syncfs(2) is available.
* NEWS: Mention the new feature.
* doc/coreutils.texi (sync invocation): Document the new feature.
* src/sync.c (usage): Describe that arguments are now accepted.
(main): Use syncfs(2) to flush buffers for the file system which
contain the specified
* configure.ac: Check if syncfs(2) is available.
* NEWS: Mention the new feature.
* doc/coreutils.texi (sync invocation): Document the new feature.
* src/sync.c (usage): Describe that arguments are now accepted.
(main): Use syncfs(2) to flush buffers for the file system which
contain the specified
sort supports --human-numeric-sort since coreutils 7.5.
Cheers,
Giuseppe
Phil Dumont writes:
> It sure would be nice if the sort command had a --human option:
>
> du -s --human * | sort --human
>
> phil
A similar patch was rejected some months ago:
http://lists.gnu.org/archive/html/bug-coreutils/2009-10/msg00143.html
As solution, Pádraig suggests to use find(1).
You can take advantage of the new utility nproc(1), distributed with
recent coreutils versions to get the number of processing units
"Alfred M. Szmidt" writes:
> A friend came up with this hack `echo -n\ '; note the space. Which is
> a bit of a cheat. And `echo -e --\\bn', which alas is not POSIXly.
POSIXly correct or not, '--\bn' is not the same as '-n'.
Giuseppe
Hey Alfred,
you can get it using:
/bin/echo -e \\x2Dn
Cheers,
Giuseppe
"Alfred M. Szmidt" writes:
> Here is a fun one, how does one output `-n' (literal string) (or any
> other option that echo accepts) using echo?
>
> $ /bin/echo --version|head -n1
> echo (GNU coreutils) 8.4
> $ /bin/echo
it is a bash feature, you can find more information using `info bash'.
Anyway, the proper place for bash related questions is the
bug-b...@gnu.org mailing list.
Cheers,
Giuseppe
Sameer Kumbhare writes:
> Hi,
> I dont know whether to call this a bug, or a what.
> But. whenever I go n press "
jida...@jidanni.org writes:
> The tee(1) documents fail to say what happens when tee is given no
> arguments. Do say what is going on in
> $ echo o|tee|tee|tee
"The `tee' command copies standard input to standard output and also to
any files given as arguments."
it looks quite clear to me, if yo
when --all fails for any reason, I think we should try with the number
of available processing units, at least it is a more accurate value than
return 1 (and document this behaviour).
Bruno, Jim, what do you think?
Cheers,
Giuseppe
"Dmitry V. Levin" writes:
> Hi,
>
> The recently introduced
oday :-)
This patch should fix the problem, other tests remain green.
>From f108dc01f86fb8df057172d2bafd8224759be884 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Wed, 30 Dec 2009 00:20:24 +0100
Subject: [PATCH] tail: ensure the wd is not already present in the hash table
before add
.
this patch makes your test case pass successfully. It must be applied
after the three patches you have sent in another thread.
Cheers,
Giuseppe
>From e249f9ab639d318d709eed722b57bc232a7657c1 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Tue, 29 Dec 2009 14:59:24 +0100
Subject:
Hello Pádraig,
Pádraig Brady writes:
> It doesn't handle the above remount case though
> as if I mount the parent dir of a file or bind mount the file itself
> then there are no inotify notifications. This remounting issue is
> independent of nfs anyway. So can inotify handle this or will we
>
Hello,
Jim Meyering writes:
> Pádraig Brady wrote:
>> I've just noticed that `tail -f` will not work over NFS
>> as changes on the remote system will not go through
>> the local VFS and so will not be noticed by inotify.
>>
>> So what to do? I suppose we could statfs("filename")
>
> Yes, I think
Hello,
Erik Auerswald writes:
> Why have an option for the default operation at all? If --available is
> the same as specifying no option and the only other mode of operation is
> --all, only the --all option should be recognised. There is no need for
> --available.
it is not very common case b
ns, so OK
> leave them as separate options.
>
> I'll hope to commit this soon.
I amended this change and the bug in the texinfo documentation reported
by Paolo. I hope it is fine now.
Cheers,
Giuseppe
>From 3e639852488e44c88c040d8b993dade4a3e81407 Mon Sep 17 00:00:00 2001
Fro
rridable, avoiding the same prefix allows to use the
shorter forms $(nproc --c) and $(nproc --o).
What do you think?
Giuseppe
>From d07e645265b38c5648e47467a5ffd829bbe966f2 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Sat, 31 Oct 2009 18:59:50 +0100
Subject: [PATCH] nproc
# echo 1 > /sys/devices/system/cpu/cpu1/online
# grep '^proc' /proc/cpuinfo | wc -l
2
Regards,
Giuseppe
>From 31b047ef9f0e83b7f6387bdd7e628cbb17f24079 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Sat, 31 Oct 2009 18:59:50 +0100
Subject: [PATCH] nproc: A new pro
Hi Jim,
thanks for your quick review.
Jim Meyering writes:
> Giuseppe Scrivano wrote:
>> I included what we have discussed into my patch. I renamed the new
>> program to `nproc', now it accepts two options: --available and
>> --installed.
>> By default --avai
;= nproc --installed.
Any comment?
Cheers,
Giuseppe
>From 4665e1801f73eeba98cad9988c5d5829bad03a37 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Sun, 25 Oct 2009 19:04:41 +0100
Subject: [PATCH] nproc: A new program to count the number of processors
* AUTHORS: Add my name.
* NEWS:
Bruno Haible writes:
> Pádraig Brady wrote:
>> >> Of course this should only apply if its effect is not externally
>> >> observable; if I have a very small file B and a very large file A, and I
>> >> can get
>> >>
>> >> $ md5sum --threads A B
>> >> abcdabcdabcdabcdabcdabcdabcdabcd B
>> >>
Hi Bruno,
Bruno Haible writes:
>> No, it should not be a hardware inspection tool but a portable
>> tool to help shell scripts to have an idea of how many
>> processes can be executed at the same time. If we get too
>> much into details then we loose portability
>
> Good. This is important info
Pádraig Brady writes:
> Hmm it's a bit surprising that min()/max() are not available
> as $((shell arithmetic)) or in `expr`. Consequently I agree that
> adding the option you suggest is useful. What will we call it though?
I remember a recent discussion about adding min/max to sort. Is still
Bruno Haible writes:
> This program (and the underlying gnulib 'nproc' module) is IMO too simplistic.
>
> First of all, is the program meant to be a hardware inspection tool (like
> "hwinfo --cpu")? Or is meant to be an auxiliary program for helping shell
> scripts that want to dispatch tasks on
version of the new program,
it is a simple wrapper around the gnulib nproc module, thanks to Bruno
to have done the real work.
Any comment?
Cheers,
Giuseppe
>From e3bff6a4dd2fe9560c7922e877ab57081a083c58 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Sun, 25 Oct 2009 19:04:41 +
Jim Meyering writes:
> As far as I know, there is nothing portable.
> Want to add another program to coreutils?
> With what Bruno has just added to gnulib's nproc module,
> we should have most platforms covered.
If nobody is already working on it, I can start doing it.
What about the name? "nc
Jim Meyering writes:
Thanks again for your notes. I amended them into the patch.
Cheers,
Giuseppe
>From 3f0f5744899afc15e69554220be836f673b1dad3 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Tue, 20 Oct 2009 10:49:17 +0200
Subject: [PATCH] tests: add a new test that checks fo
>From e5532992b1e7c018e5754c7082c2d9ac256cee3d Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Tue, 20 Oct 2009 10:49:17 +0200
Subject: [PATCH] tests: add a new test that checks for a possible `tail' race.
If new data is available between the initial read and tail registers the inotify
watch descriptors, ensure that it
.
Cheers,
Giuseppe
>From e86c16342e856bec744ea01b8a2f8ab1b8695d63 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Tue, 20 Oct 2009 10:49:17 +0200
Subject: [PATCH] tests: add a new test that checks for a possible `tail' race.
If new data is available between the initial read
Jim Meyering writes:
>> What about a new switch to `arch'?
>
> Sorry, no.
> arch is not installed by default, for portability reasons.
Does uname have the same problem? It already has a "--processor"
option and IMHO it would be better to get similar information using
the same tool.
By the way,
Pádraig Brady writes:
> With -n4 only 1 process would be started.
> Could you repeat with -n1 please for comparison.
> One would only need to increase -n for large numbers of files.
Sprry the mistake. In this case results are equal.
$ time ./sha1sum --threads=2 /tmp/test_files/*
a91f3339c2025
Jim Meyering writes:
>> Hmm, I could see it being useful to specify NCPUs-1 also.
>> I wonder is there a general external method to determine
>> the number of CPUs.
>
> As far as I know, there is nothing portable.
> Want to add another program to coreutils?
> With what Bruno has just added to gnu
Hi Pádraig,
> How does it compare to:
>
> files_per_process=10
> cpus=4
> find files | xargs -n$files_per_process -P$cpus md5sum
>
> I would expect it to be a bit better as file_per_process
> could be very large, thus having less overhead in starting
> processes. Though is the benefit worth the ex
001
From: Giuseppe Scrivano
Date: Sun, 18 Oct 2009 00:19:25 +0200
Subject: [PATCH] md5: accepts a new --threads option
* NEWS: Mention it.
* bootstrap.conf: Use the `nproc' and `pthread' modules from gnulib.
* doc/coreutils.texi: Document the new feature.
* src/Makefile.am (md5sum, sha1s
Hi Jim,
Jim Meyering writes:
> I haven't reviewed this yet, but will do so today or tomorrow.
> I know triggering race conditions can be hard, but
> can you write a script that demonstrates the failure?
>
> This might be a good excuse to experiment with the
> now-usable-as-non-root system tap (
iuseppe
>From 2e3cf73ef68003569a797f6ae0d77d7c8a12f24d Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Mon, 12 Oct 2009 22:16:03 +0200
Subject: [PATCH] tail: fix a race condition
* NEWS (Bug fixes): Mention it.
* src/tail.c (check_fspec): New function.
(tail_forever_inotify): Ensure th
Jim Meyering writes:
> Considering the amount of complexity it adds to already-dense code
> (in spite of the fact that some is just due to indentation changes),
> for so little gain (who will use tail -f on stdin and care whether tail
> is sleep-based or inotify-based?), I'm reluctant to use it a
Hi Jim,
have you considered this patch for inclusion? I don't see a clearer way
to avoid polling without inotify fd support.
Regards,
Giuseppe
Giuseppe Scrivano writes:
> This patch changes `tail' to handle stdin separately from inotify
> events, similar to what we are alre
Eric Paris writes:
> On Tue, Sep 8, 2009 at 8:21 PM, Giuseppe Scrivano wrote:
>
>> at the moment inotify permits to add new files to be watched using their
>> path. There are situations where the file path is not know but a
>> descriptor is available. It would be
to get the same
result?
Regards,
Giuseppe
P.S.
In the attached patch I changed the syscalls table only for x86.
>From 6f3340347fb5d26000bec3a0a9cd8ef59c710922 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Tue, 8 Sep 2009 23:40:03 +0200
Subject: [PATCH] Add new syscall \`inotify_add_watch_
eparately from inotify
events, similar to what we are already doing when a --pid is specified.
Regards,
Giuseppe
>From f3010bebf9e25be9a83868b4ad9db2cc6cb6613f Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Mon, 7 Sep 2009 16:35:16 +0200
Subject: [PATCH] tail: handle &
Hi Jim,
what do you think about the following solution? It avoids to revert to
the "old" polling mechanism using "/dev/stdin" instead of "-" to
inotify_add_watch.
Cheers,
Giuseppe
diff --git a/src/tail.c b/src/tail.c
index e3b9529..016b712 100644
--- a/src/tail.c
+++ b/src/tail.c
@@ -1152,6 +1
Hello,
can you please tell us where is it documented to ask APT related
questions to this mailing list? It is not the first time Ubuntu
questions are directed here and in case this documentation should be
fixed.
Thanks,
Giuseppe
Gil Miller writes:
> E: type 'sudo' is not known on line 58 in
t; case PRESERVE_CONTEXT_OPTION:
> ...
thanks for the comments. This is the cleaned version of the patch.
Cheers,
Giuseppe
>From 8dc27341e8ed57e790a71d4b61df44e908bc73cd Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Tue, 18 Aug 2009 12:22:37 +0200
Subject: [PAT
Thanks Kamil, yes, CHAR_MAX + 1 looks like a better choice.
Are there other comments?
Giuseppe
Kamil Dudka writes:
> Hello Giuseppe,
>
> On Tue August 18 2009 12:47:06 Giuseppe Scrivano wrote:
>> diff --git a/src/nl.c b/src/nl.c
>> index 2deb314..ea7ebe6 100644
>>
Hello,
--page-increment seems the wrong name for this option, --line-increment
is clearer. what do you think of this change?
Cheers,
Giuseppe
>From e71bee2c6731fe65c07744ac95e1e4058eea773c Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Tue, 18 Aug 2009 12:22:37 +0200
Subject: [PA
Hi,
These are the results I reported (median of 5 plus an additional not
considered first run) on the Steve Reid's SHA1 implementation using the
same flags to the compiler that I used for previous tests.
GCC 4.3.3: real0m2.627s
GCC 4.4.1: real0m3.742s
In both cases it showed to
Pádraig Brady writes:
> -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586
> -mtune=generic -fasynchronous-unwind-tables -D_GNU_SOURCE=1
thanks. I did again all tests on my machine using these same options.
I repeated eac
Linus Torvalds writes:
> I pretty much can guarantee you that it improves things only because it
> makes gcc generate crap code, which then hides some of the P4 issues.
>
> I'd also suggest you try gcc-4.4, since that apparently fixes some of the
> oddest spill issues.
Thanks for the hint. I
iuseppe
>From b975a5e0849eaa46e5cf410c5bf6e2308f044d61 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Sun, 16 Aug 2009 20:53:54 +0200
Subject: [PATCH] SHA1: use a lookup table for faster hashing
* lib/sha1.c (struct sha1_pre): New member.
* lib/sha1.c (sha1_process_block): Use the lookup table to quickly find
indices to
%s"), quote (dst_name));
Too wild copy&paste :)
I included your notes in the following patch.
Cheers,
Giuseppe
>From 63c0a1840f236eebb9ba3a28d8f1e6242a7c5898 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Sat, 1 Aug 2009 19:36:48 +0200
Subject: [PATCH] cp: accept the --reflink o
>
> assert ( ! (x->reflink && x->sparse_mode != SPARSE_AUTO));
>From 75610aed5c325d14a3ef43fb2c319ace12f36c57 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Sat, 1 Aug 2009 19:36:48 +0200
Subject: [PATCH] cp: accept the --reflink option
* NEWS: Mention it.
* doc/coreutils.texi: Likewise.
*
itions, though I couldn't find a clear answer on the btrfs wiki to
this question.
Any comment?
Thanks,
Giuseppe
>From d110badaf7583acf957477bc7eda2e212b404343 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Sat, 1 Aug 2009 19:36:48 +0200
Subject: [PATCH 1/2] cp: accept the --r
Jim Meyering 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?
sure.
> Things to adjust, other than copy.c and the test:
>
Hello,
Pádraig Brady writes:
> 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.
>>
Pádraig Brady 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 for testing purpose. If you think
the r
age of sparse files instead of using "dd".
I am also considering the Jim's note doing the umount in the cleanup_
function.
Cheers,
Giuseppe
>From 7add4b337b7db0a63bca0dd0fe0f146f175163f8 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Wed, 29 Jul 2009 20:31:20 +0200
Subje
m 0348010828d201c0790c06e1427cc4b813c605db Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Wed, 29 Jul 2009 20:57:29 +0200
Subject: [PATCH 2/2] tail: exit successfully on watched process death
* src/tail.c (tail_forever_inotify): If a PID is specified and the
watched process is death, exit
Hi Pádraig,
Pádraig Brady writes:
> How different exactly?
> OK I tried this myself on F11 with inconclusive results.
I can't replicate it now, all tests I am doing report that blocks used
before and after the clone are the same. Probably yesterday the
difference I noticed was in reality the
it without check
more than N consecutive times." What do you think?
Regards,
Giuseppe
>From 65f2737fa6e2519fbccbad7d285ca8923a893057 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Sun, 26 Jul 2009 13:22:57 +0200
Subject: [PATCH] tail: use the inotify backend when a PID is specifie
Jim Meyering writes:
>> Another possible issue with this I can think of is
>> depending on the modification pattern of the COW files,
>> the modification processes could fragment the file or
>> more seriously be given ENOSPC errors.
>
> I hope btrfs takes care of this behind the scene.
>
> How do
t a week.
I modified tail as you suggested.
Regards,
Giuseppe
>From 862c9d934dc2ee188e9fe29985e463e2ec4d16ca Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Sun, 26 Jul 2009 13:22:57 +0200
Subject: [PATCH] tail: use the inotify backend when a PID is specified.
* src/tail.c (tail_forever_i
rse=auto is used.
Regards,
Giuseppe
>From 747c96980acc25220cc436210403cdcaed6239c9 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Sat, 25 Jul 2009 16:35:27 +0200
Subject: [PATCH] cp: support the btrfs file system clone operation.
* src/copy.c(copy_reg): Use the btrfs clone operation if
Jim Meyering writes:
>> ..., a cloned partially-sparse file on btrfs takes less
>> space than a fully-sparse copied file.
>
> That is not true. A fully-sparse file takes less space
> than a partially-sparse one.
Sorry I wasn't clear, I wanted to say that a cloned file in any case
take less spac
Hi Jim,
Jim Meyering writes:
> However, but what about cp's --sparse option?
> btrfs supports sparse files, so this new code will have to
> honor that. The trouble is that there is currently no option
> to say "preserve precisely and only whatever holes are present
> in src", which is the behav
Jim Meyering writes:
> Doesn't that constant, 1074041865, have a symbolic name?
> Maybe BTRFS_IOC_CLONE?
Yes, it is exactly BTRFS_IOC_CLONE and it is defined in the
fs/btrfs/ioctl.h file.
>> Is there an easy and quick way to determine which file system is used by
>> a file? Probably it would
0swaps
$ env time ./cp foo baz
0.00user 0.00system 0:00.40elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
5744inputs+32outputs (1major+253minor)pagefaults 0swaps
Cheers,
Giuseppe
>From deea0ee0c2a521aae5a89d8613f937707d8f0e7b Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Sat, 25
y" group is not present on all systems, for example on Debian
it is "nogroup" so IMHO it is better to find it at runtime using the
"nobody" user's group.
The second patch is just a small refactoring.
Cheers,
Giuseppe
>From a089ec8770afa349f1e0b6e9d090d739f0afe6dd
Hi Jim,
Jim Meyering writes:
> I'm not convinced that adding a lot of new code just to make tail -f
> handle a far-fetched case like that is worthwhile. But that's just
> my opinion, and if someone can present a use-case that makes it seem
> the additional code would be put to good use, I'll ke
Hi Jim,
Jim Meyering writes:
> I don't (yet?) see why a tree would be the preferred data structure.
>
> ...
Because inotify doesn't add recursive watchers. For example, you want
to follow by name `/var/foo/bar', and `/var/foo' doesn't exist yet. To
catch the event for the `bar' file creation,
e to be fixed before the upcoming release.
>From 8fbe1d2d1f666a0428f41d03831e18d4d1b56e89 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Thu, 2 Jul 2009 23:38:46 +0200
Subject: [PATCH 1/2] tail: avoid a problem for kernels prior to 2.6.21
* src/tail.c (tail_forever_inotify): Handle th
Is https://savannah.gnu.org/bugs/?func=additem&group=coreutils the page
you are looking for?
Giuseppe
jida...@jidanni.org writes:
> Logged in to https://savannah.gnu.org/
> the user cannot find the link to "report a new bug".
___
Bug-coreutils maili
hat case.
Oops, I was using a different events mask for re-added files. I added
your test case to the tests suite now.
Thanks,
Giuseppe
This is the new version:
>From 106b1d32a6956f902109bffdf87e7897210c0e04 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Tue, 2 Jun 2009 08:2
Hello,
if you need a specific wc output field, the words count in this case,
you can use the command `wc -w FILE'. Is it what you want?
Regards,
Giuseppe
Iram CHELLI writes:
> Hello,
>
>
> i am using wc in shell scripts
>
> the exact command is:
>
> wc FILE | cut -d " " -f 2
>
> it usual
the new
tests as previously reported.
Cheers,
Giuseppe
>From 28cc1f8e2582adb269babd5a6371fc5797f9ba52 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Tue, 2 Jun 2009 08:28:23 +0200
Subject: [PATCH] tail: Use inotify if it is available.
* NEWS: Document the new feature.
* m4/jm-macros.m4: Check if inotify is present.
est" in place of "["..."]"
I changed it.
>> +test "$(wc -w < tail.err) eq 0" || fail=1
>
> This can be written more simply:
>
> test -s tail.err && fail=1
Done.
The new version includes all these changes.
Cheers,
Giuseppe
>Fr
s suite
now.
Regards,
Giuseppe
>From 529e1c2ba2a74168995de9ae7f8b9efa0d2d71c4 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Tue, 2 Jun 2009 08:28:23 +0200
Subject: [PATCH] tail: Use inotify if it is available.
* NEWS: Document the new feature.
* m4/jm-macros.m4: Check if inotify
Jim Meyering writes:
> Actually, there may be a nice way to allow --pid=PID to
> integrate seamlessly with inotify support.
>
> I think you can add an IN_DELETE_SELF inotify watch on the "/proc/PID"
> directory. I suspect that every system with inotify support also
> has usable /proc/PID directo
Hi Jim,
Jim Meyering writes:
> Oh, and it'd be better to put that test in m4/jm-macros.m4,
> not in configure.ac.
Ok, I'll move it.
>> AC_CONFIG_FILES(
>>Makefile
>>doc/Makefile
> ...
>> + if (len <= evbuff_off)
>> +{
>> + len = read (wd, evbuff, evlen);
>
> Ple
Jim Meyering writes:
> However, my first manual test provoked this surprising diagnostic:
>
> $ touch k && src/tail -F k &
> src/tail: cannot watch parent directory of `k': No such file or directory
>
> The following patch fixes that.
> Go ahead and fold it into yours.
Thank you. Do you wan
tail-2/pid) with
additional tests for the --pid option.
Regards,
Giuseppe
>From f0824b8b79c1fb22e9a48cbf831a87433fc4d3e8 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Tue, 2 Jun 2009 08:28:23 +0200
Subject: [PATCH] tail: Use inotify if it is available.
* NEWS: Document the new fea
ep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Tue, 2 Jun 2009 08:28:23 +0200
Subject: [PATCH] tail: Use inotify if it is available.
* NEWS: Document the new feature.
* configure.ac: Check if inotify is present.
* src/tail.c (tail_forever_inotify): New function.
(main): Use the inotify-based f
ere are other recoverable cases but if we want to force it to re-try
read then we will need to avoid an end-less loop when there is an
unrecoverable situation. What do you think?
Regards,
Giuseppe
>From 706774fb68dde926343cc906dc627891e42504a9 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
D
Hi,
I noticed that the fd is not closed properly if the fstat call fails.
This trivial patch solves it.
Giuseppe
>From 0f93ba2a0673a689bbeaf747b876f6f8c4bc6cae Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Sat, 30 May 2009 21:41:26 +0200
Subject: [PATCH] tail: don't leave open
onitor a path that doesn't exist yet and be alerted
when it is created without polling?
Giuseppe
>From b5cad2d1e51781b18e53eac7b102922319909f5b Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Sat, 30 May 2009 13:31:58 +0200
Subject: [PATCH] tail: Use inotify if it is available.
* NEWS: Document the n
he attached patch?
Cheers,
Giuseppe
>From aa815abdd3cbf2ad15d769a1f4cb6100e3a975e5 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Sat, 30 May 2009 13:31:58 +0200
Subject: [PATCH] tail: Use inotify if it is available.
* NEWS: Document the new feature
* configure.ac: Check
Eric Blake writes:
> The point is that setuidgid is not installed. It exists only for the
> purposes
> of the testsuite. If it were an installed app, then yes it would make sense
> to
> keep it around, although perhaps rewritten as a wrapper around the new chroot
> functionality. But sinc
Hi Jim,
Jim Meyering writes:
> setuidgid appears to be subsumed by chroot with the new options.
> If we can remove setuidgid.c, that code is no longer duplicated,
> so there's less (no?) motivation to move it into gnulib.
If you want to remove setuidgid then I don't see any reason to move
the s
Hi Eric,
Eric Blake writes:
> Would it be worth starting to patch the testsuite to replace 'setuidgid -g
> list usr cmd arg' with 'chroot --user usr --groups=list / cmd arg' in
> order to give this feature more exposure and reduce our dependence on
> uninstalled apps?
IMHO, since chroot now all
Pádraig Brady writes:
> + Assume that numbers are properly abbreviated.
> + i.e. input will never have both 5000K and 6M. */
I think this is a too strong assumption. I wouldn't be surprised to
find, for example, both 1M and 1500K in a data set.
Are there problems to normalize values using
arate library, so it can be shared with setuidgid that
at the moment doesn't support group names but only group IDs and this is
what setuidgid will get back.
Cheers,
Giuseppe
>From 0b305c281fc7575b3989b0f80fe452918cf93f62 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Fri, 1 May 2009 2
Pádraig Brady writes:
>> +#ifndef MAXGID
>> +# define MAXGID GID_T_MAX
>> +#endif
>
> Why add the new MAXGID name?
I took this code from the gnulib userspec.c file. I guess there are
cases when MAXGID is defined and GID_T_MAX is not, and in such case it
is better to use the real value of MAXGID
D
and OpenBSD; now I removed this option and I kept only the long-named
version --groups.
Regards,
Giuseppe
>From 60834e55e2826d41de545794123a7007536873e4 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Fri, 1 May 2009 23:50:11 +0200
Subject: [PATCH] Chroot now accepts the options --
Jim Meyering writes:
> In the future, please send patches by mail to the bug-coreutils list.
> Most of the people who will review them here prefer that.
Sorry, I thought it was redundant to post both on the ML and on
savannah. I'll send the next version to the bug-coreutils ML.
> If you'd like
1 - 100 of 109 matches
Mail list logo
