Re: Adding humanize_number to coreutiles?

2012-02-07 Thread Pádraig Brady
On 02/07/2012 03:36 AM, Peng Yu wrote: > Hi, > > Several commands in coreutils have the -h option. I'm wondering > whether anybody in the develop team also thinks that it is worthwhile > to export it as a standalone command. If so, I'd recommend add such > convenient command in coreutiles. As I do

bug#10686: mv: moving hardlink of a softlink to the softlink does nothing

2012-02-07 Thread Bernhard Voelker
On 02/07/2012 11:45 AM, Michael Felt wrote: > Just reading - for reference only - AIX 5.3, and I expect new versions behave > as follows > (second link becomes a hardlink to original file, mv "removes" one hard link, > i.e. original file (as inode) remains. > > root@x105:[/tmp/test]touch f > ro

bug#10735: chmod +x

2012-02-07 Thread francky . leyn
Dear Bob, is there any way I could suppress the warning given by chmod +x? Best regards, FRancky - Oorspronkelijk e-mail - > francky.l...@telenet.be wrote: > > some more questions. > > I abstract a file system as something where each dir/file has a > > header > > where all properties r

bug#10735: chmod +x

2012-02-07 Thread Paul Eggert
On 02/07/2012 05:49 AM, francky.l...@telenet.be wrote: > is there any way I could suppress the warning given by chmod +x? You can suppress all warnings with the shell command: chmod +x file 2>/dev/null;: This is usually not a good idea. The warnings are there for a reason.

uniq --accumulate

2012-02-07 Thread Peng Yu
Hi, Suppose that I have a table of the following, where the last column is a number. I'd like to accumulate the number of rows that are the same for all the remaining columns. A 1 A 3 X 2 X 3 Y 3 The result will be the following. Although this is can be easily done by awk, etc, I'm wondering if

bug#10735: chmod +x

2012-02-07 Thread francky . leyn
Dear Paul, thanks for your reply, but this was not what I meant. I have scripts that work fine on a full Linux platform (ext filesystem). However, if I use those scipts (that use chmod +x), I get a lot of warnings. Thing I dislike to see, and are confusing. I was wondering wether I couldn't writ

Re: uniq --accumulate

2012-02-07 Thread Pádraig Brady
On 02/07/2012 03:56 PM, Peng Yu wrote: > Hi, > > Suppose that I have a table of the following, where the last column is > a number. I'd like to accumulate the number of rows that are the same > for all the remaining columns. > > A 1 > A 3 > X 2 > X 3 > Y 3 > > The result will be the following. A

Re: uniq --accumulate

2012-02-07 Thread Assaf Gordon
Pádraig Brady wrote, On 02/07/2012 11:00 AM: > On 02/07/2012 03:56 PM, Peng Yu wrote: >> >> Suppose that I have a table of the following, where the last column is >> a number. I'd like to accumulate the number of rows that are the same >> for all the remaining columns. >> > > Thanks for the sugges

Re: uniq --accumulate

2012-02-07 Thread Peng Yu
On Tue, Feb 7, 2012 at 10:21 AM, Assaf Gordon wrote: > Pádraig Brady wrote, On 02/07/2012 11:00 AM: >> On 02/07/2012 03:56 PM, Peng Yu wrote: >>> >>> Suppose that I have a table of the following, where the last column is >>> a number. I'd like to accumulate the number of rows that are the same >>>

Re: uniq --accumulate

2012-02-07 Thread Peng Yu
>        (1)  The input file/stream should be sorted/grouped by the -grp. > columns Do you actually mean that the rows are treated just like uniq does? I.e, only adjacent rows are subjected to grouping? If so, the document should be reworded to reflect this meaning. -- Regards, Peng

Re: uniq --accumulate

2012-02-07 Thread Peng Yu
>        -o -ops         Specify the operation that should be applied to opCol. >                        Valid operations: >                            sum, count, min, max, >                            mean, median, mode, antimode, >                            stdev, sstdev (sample standard dev.),

Re: dd: add 'skip_bytes' and 'count_bytes' operands

2012-02-07 Thread Jérémy Compostella
> On 02/06/2012 03:24 PM, Jérémy Compostella wrote: > >> Hmm, shouldn't there be a seek_bytes param too for consistency? > > That was effectively my first mail question. As you talk about it in > > your explanation addition in coreutils.texi I guess I should start > > implementing it ? > > I think

bug#10561: stat unclear about size on disk and type of blocks discussed

2012-02-07 Thread Filipus Klutiero
Hi Pádraig, On 2012-01-20 19:03, Pádraig Brady wrote: On 01/20/2012 05:47 PM, Filipus Klutiero wrote: Hi Pádraig and Jim, On 2012-01-20 09:15, Pádraig Brady wrote: On 01/20/2012 02:03 PM, Jim Meyering wrote: Pádraig Brady wrote: ... As for %o, if you'd ask me what "I/O block size" means wit

bug#10561: stat unclear about size on disk and type of blocks discussed

2012-02-07 Thread Pádraig Brady
On 02/07/2012 06:26 PM, Filipus Klutiero wrote: > Hi Pádraig, > > On 2012-01-20 19:03, Pádraig Brady wrote: >> On 01/20/2012 05:47 PM, Filipus Klutiero wrote: >>> Hi Pádraig and Jim, >>> >>> On 2012-01-20 09:15, Pádraig Brady wrote: On 01/20/2012 02:03 PM, Jim Meyering wrote: > Pádraig Br

bug#10561: stat unclear about size on disk and type of blocks discussed

2012-02-07 Thread Filipus Klutiero
On 2012-02-07 13:55, Pádraig Brady wrote: On 02/07/2012 06:26 PM, Filipus Klutiero wrote: Hi Pádraig, On 2012-01-20 19:03, Pádraig Brady wrote: On 01/20/2012 05:47 PM, Filipus Klutiero wrote: Hi Pádraig and Jim, On 2012-01-20 09:15, Pádraig Brady wrote: On 01/20/2012 02:03 PM, Jim Meyering

Re: dd: add 'skip_bytes' and 'count_bytes' operands

2012-02-07 Thread Pádraig Brady
On 02/07/2012 06:25 PM, Jérémy Compostella wrote: >> On 02/06/2012 03:24 PM, Jérémy Compostella wrote: >> >> Hmm, shouldn't there be a seek_bytes param too for consistency? >> > That was effectively my first mail question. As you talk about it in >> > your explanation addition in coreutils.texi I g

bug#10561: stat unclear about size on disk and type of blocks discussed

2012-02-07 Thread Eric Blake
On 02/07/2012 12:20 PM, Filipus Klutiero wrote: > > So are you saying that stat cannot display a file's size on disk? Not without inventing a new % modifier, or else you doing the math yourself. So maybe it is worth adding a new one, as in: %S Allocated size (same as %b * %B) >> I don't see a

bug#10755: stat: Please add directive to display size on disk

2012-02-07 Thread Filipus Klutiero
The other day I tried figuring out how much disk space a small file took. I used stat, but I only realized today that stat does not provide that information directly, as explained by Eric Blake and Pádraig Brady in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10561 This information is provided

bug#10561: stat unclear about size on disk and type of blocks discussed

2012-02-07 Thread Filipus Klutiero
Hi Eric, On 2012-02-07 14:44, Eric Blake wrote: On 02/07/2012 12:20 PM, Filipus Klutiero wrote: So are you saying that stat cannot display a file's size on disk? Not without inventing a new % modifier, or else you doing the math yourself. Thank you very much. I apologize for much of what I

bug#10755: stat: Please add directive to display size on disk

2012-02-07 Thread Paul Eggert
On 02/07/2012 12:10 PM, Filipus Klutiero wrote: > Size on disk We don't know it's a disk drive; it might be any storage device that contain a file system. Perhaps a better shorthand string would be "Allocation"? That's even shorter, and it conveys what's going on.

bug#10735: chmod +x

2012-02-07 Thread Paul Eggert
On 02/07/2012 07:59 AM, francky.l...@telenet.be wrote: > I was wondering wether I couldn't write something like > > if [not on NTFS filesystem] then > chmod +x No doubt you can write something like that. I don't use NTFS, so I'm not a good source of advice about the details.

bug#10735: chmod +x

2012-02-07 Thread Eric Blake
On 02/07/2012 02:30 PM, Paul Eggert wrote: > On 02/07/2012 07:59 AM, francky.l...@telenet.be wrote: >> I was wondering wether I couldn't write something like >> >> if [not on NTFS filesystem] then >> chmod +x > > No doubt you can write something like that. > I don't use NTFS, so I'm not a good s

bug#10755: stat: Please add directive to display size on disk

2012-02-07 Thread Filipus Klutiero
On 2012-02-07 15:54, Paul Eggert wrote: On 02/07/2012 12:10 PM, Filipus Klutiero wrote: Size on disk We don't know it's a disk drive; it might be any storage device that contain a file system. I agree. I see an advantage in using the term "Size on disk": it is well known from Windows ( http