It would both be logical, and help with testing (where one wouldn't have to
change one's login script) if dircolors tried to load ~/.dircolors if no
database is given and the file exists.
--
http://rrt.sc3d.org/ | fantasize, a. the largest you can imagine
On Sat, 19 Jul 2008, Jim Meyering wrote:
Reuben Thomas <[EMAIL PROTECTED]> wrote:
It would both be logical, and help with testing (where one wouldn't
have to change one's login script) if dircolors tried to load
~/.dircolors if no database is given and the file exists.
Or
On Sat, 19 Jul 2008, Jim Meyering wrote:
Reuben Thomas <[EMAIL PROTECTED]> wrote:
On Sat, 19 Jul 2008, Jim Meyering wrote:
Reuben Thomas <[EMAIL PROTECTED]> wrote:
It would both be logical, and help with testing (where one wouldn't
have to change one's login script)
On Sat, 19 Jul 2008, Jim Meyering wrote:
Sorry. Not one other program in coreutils' set of 100+ does that,
and as far as I'm concerned, dircolors does not deserve an exception.
Right-o.
In addition, if there's a vendor-supplied /etc/DIR_COLORS file on
your system, odds are good that it is o
On Sat, 19 Jul 2008, Jim Meyering wrote:
Reuben Thomas <[EMAIL PROTECTED]> wrote:
On Sat, 19 Jul 2008, Jim Meyering wrote:
Reuben Thomas <[EMAIL PROTECTED]> wrote:
It would both be logical, and help with testing (where one wouldn't
have to change one's login script)
These two switches are necessary for POSIX compatibility. I note that bash's
pwd does support them; is the intention that bash's built-in pwd, which
does, should fill this gap in a GNU system?
--
http://rrt.sc3d.org/ | Quidquid latine dictum sit, altum viditur (Anon)
_
Here's a suggestion that would be a lot simpler to implement: have pwd
implement -P as a no-op, and document the lack of -L, and the conflict with
the POSIX default behaviour. I'd be happy to write a documentation patch.
That will enlighten users; if anyone cares enough about coreutils's pwd
s
On Fri, 21 Nov 2008, Jim Meyering wrote:
But now, when I see it's so easy to roll your own,
I wonder if it's worth adding a C program to do that for you.
Opinions?
The most important thing is that this apparently long-standing problem be
fixed in the way that places the least burden on the u
Hi,
If I do "ls -l |head" on a directory with many files in it, it takes a long
time to complete, suggesting that it has read the entire directory. Since no
sorting is involved, why has it done this?
--
http://rrt.sc3d.org/
sane, a. having tragedy in the heart and comedy in the head (Chester
On Mon, 25 May 2009, Eric Blake wrote:
Huh? Sorting has indeed been done, unless you requested ls -U.
Indeed, stupid me (and thanks to the others who pointed out my error).
So, I'll try again:
ls -lU|head seems to look at all files in directory. It takes just as long
as ls -l|head, yet it'
On Mon, 25 May 2009, Jim Meyering wrote:
To do what he wants you have to know that ls -1U is the only
way to get one output entry per readdir call.
Reuben, you want to do it like this:
ls -1U|head|xargs ls -l
Thanks for the hint about -1, but this doesn't seem to make any difference:
I run
On Mon, 25 May 2009, Dr. David Alan Gilbert wrote:
* Reuben Thomas (r...@sc3d.org) wrote:
On Mon, 25 May 2009, Jim Meyering wrote:
To do what he wants you have to know that ls -1U is the only
way to get one output entry per readdir call.
Reuben, you want to do it like this:
ls -1U|head
On Mon, 25 May 2009, Jim Meyering wrote:
Reuben Thomas wrote:
On Mon, 25 May 2009, Jim Meyering wrote:
To do what he wants you have to know that ls -1U is the only
way to get one output entry per readdir call.
Reuben, you want to do it like this:
ls -1U|head|xargs ls -l
Thanks for the
On Mon, 25 May 2009, Jim Meyering wrote:
Pádraig Brady wrote:
Reuben Thomas wrote:
On Mon, 25 May 2009, Jim Meyering wrote:
To do what he wants you have to know that ls -1U is the only
way to get one output entry per readdir call.
Reuben, you want to do it like this:
ls -1U|head|xargs
On Mon, 25 May 2009, Jim Meyering wrote:
Reuben Thomas wrote:
On Mon, 25 May 2009, Jim Meyering wrote:
Pádraig Brady wrote:
Reuben Thomas wrote:
On Mon, 25 May 2009, Jim Meyering wrote:
To do what he wants you have to know that ls -1U is the only
way to get one output entry per readdir
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.
This is aimed at those who wish to make sure their data is deleted.
However, it may falsely reassure those who wish to recover deleted
data. I suggest add
2010/3/10 Pádraig Brady :
> 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 usua
On 10 March 2010 14:17, C de-Avillez wrote:
> On Wed, 10 Mar 2010 14:08:33 +
> Reuben Thomas wrote:
>
>> 2010/3/10 Pádraig Brady :
>> > How about just doing: s/is usually/might be/
>>
>> That seems to me to go a little too far towards reassuring the use
On 10 March 2010 23:18, Keisial wrote:
> Reuben Thomas wrote:
>>
>> On 10 March 2010 14:17, C de-Avillez wrote:
>>
>>>
>>> How about "... it might be possible, but not easy, to recover ..."?
>>>
>>
>> I am also trying to co
On 10 March 2010 23:52, Keisial wrote:
> Reuben Thomas wrote:
>>
>> On 10 March 2010 23:18, Keisial wrote:
>>
>>>
>>> Reuben Thomas wrote:
>>>>
>>>> I am also trying to convey the fact that an expert can offer recover
>>&g
Just to check before I go to the trouble of getting patch out, are we
happy with:
Note that if you use rm to remove a file, it might be possible to
recover some of its contents, given sufficient expertise and/or
time. For greater assurance that the file is truly unrecoverable,
consider using shre
I just had a situation where this would have been useful. I tried -v
--ignore-fail-on-non-empty, but of course it told me about every directory
it processed, which is fine, but not what I wanted.
--
http://rrt.sc3d.org/ | violence, n. bravery for cowards
_
On Wed, 15 Aug 2007, Aviad Lahav wrote:
I'm sorry but this is getting much too religious debate,
Maintaining multi-platform utilities on which users of many of those
platforms depend minute-by-minute is a tricky enterprise. I don't see any
"religious debate" here, only a platform-specific ve
On Wed, 15 Aug 2007, Bob Proulx wrote:
Reuben Thomas wrote:
I just had a situation where this would have been useful. I tried -v
--ignore-fail-on-non-empty, but of course it told me about every directory
it processed, which is fine, but not what I wanted.
How about this?
$ mkdir -p 1/2/3
On Wed, 15 Aug 2007, Jim Meyering wrote:
Reuben Thomas <[EMAIL PROTECTED]> wrote:
I just had a situation where this would have been useful. I tried -v
--ignore-fail-on-non-empty, but of course it told me about every
directory it processed, which is fine, but not what I wanted.
Why add
On Thu, 16 Aug 2007, Jim Meyering wrote:
Andreas Schwab <[EMAIL PROTECTED]> wrote:
Reuben Thomas <[EMAIL PROTECTED]> writes:
In this case, I don't see a good way of getting the same information. The
best way I could come up with that was short enough for command-line use
was
The man pages wisely direct the reader to the info documentation, but since
coreutils's documentation is now in one big info file, "info cat", for
example, doesn't work (it gives me the man page again on my system); you
have to say "info coreutils cat".
This is Debian bug #411722:
http://bugs
The documentation says:
The default mode is to print a line with checksum, a character
indicating type (`*' for binary, `
' for text), and name for each FILE.
There are two problems here. First, a small one: the second character
is a space character, which needs to be non-breaking, and preferabl
On 17 September 2011 14:15, Jim Meyering wrote:
> Reuben Thomas wrote:
>> The documentation says:
>>
>> The default mode is to print a line with checksum, a character
>> indicating type (`*' for binary, `
>> ' for text), and name for each FILE.
>&g
ng
through help2man (perhaps a Unicode non-breaking space would work, but
it doesn't seem sensible to try!).
>From bd0ed380c7050a1b55fca71da075fd9853442b1c Mon Sep 17 00:00:00 2001
From: Reuben Thomas
Date: Sat, 17 Sep 2011 16:05:17 +0100
Subject: [PATCH] md5sum: clarify what is meant by b
coreutils.texi says:
An earlier version of this chapter appeared in
@uref{http://www.linuxjournal.com/article.php?sid=2762, the
@cite{What's GNU?} column of @cite{Linux Journal}, 2 (June, 1994)}.
But in coreutils.info this comes out as just
An earlier version of this chapter appeared in 2 (June
Patch:
>From 3c1b7d442dc6161e3c88703c9acc3f768f9ba689 Mon Sep 17 00:00:00 2001
From: Reuben Thomas
Date: Wed, 1 Aug 2012 22:35:38 +0100
Subject: [PATCH] doc: Add tip on reversing a file byte-by-byte
* doc/coreutils.texi: Note how to use tac to reverse a file
byte-by-byte.
---
On 1 August 2012 22:50, Eric Blake wrote:
>
> Cool tip. But not quite accurate - you need a literal newline instead
> of a space on the other side of that regex alternation.
Sorry, I just copied what I found at
http://stackoverflow.com/questions/6438099/linux-command-line-tool-to-reverse-byte-o
On 2 August 2012 15:00, Andreas Schwab wrote:
> Eric Blake writes:
>
>> On 08/02/2012 07:18 AM, Andreas Schwab wrote:
[blah blah blah]
All this just because there's no standard interface in coreutils (or
indeed other GNU programs) to control the regexp engine, so you can
make "." match any char
--help says:
if an existing destination file cannot be opened, remove
it and try again (redundant if the -n
option is used)
That use of the word "redundant" suggests to the unwary reader that if
-n is used, then -f is not needed, but in fact (AFAICT) it means that
if -
On Fri, 14 May 2004 15:53:04 +0600 (YEKST), Victor Porton offered his handy
"inplace" script to coreutils, which runs a filter on a file in-place. A
couple of replies said there was no need for this as one could do in-place
editing with perl or sed, but I think that was misguided, as the point of
i
On 29 November 2012 15:35, Pádraig Brady wrote:
>
> I definitely think this is worthwhile.
>
Great!
> Where to put such a script is an issue.
> We were thinking of a contrib/ folder for higher level
> scripts like this that could leverage coreutils/
> Translations in the shell script was one t
On 1 February 2013 21:36, Paul Eggert wrote:
> On 02/01/13 11:14, Reuben Thomas wrote:
>
> > Given how long it took how many experts to come up with a valid
> > incantation, it seems to me it *is* a useful documentation example.
>
> Sure, but the valid incantation is a
On 1 February 2013 21:46, Paul Eggert wrote:
> On 02/01/13 13:43, Reuben Thomas wrote:
> > What about a way to do it on a GNU system?
>
> I think it works if you set LC_ALL='C', as the
> C locale is unibyte on a GNU system, but someone
> should double-check this.
It would be helpful to this addle-pated individual if du would output the
same units as it accepts as SIZE inputs, so that one could more readily
tell whether one was getting 1000-based or 1024-based units.
For additional clarity, it would help if for output the suffix were "B" as
at present for 1
On 22 May 2014 23:58, Pádraig Brady wrote:
> On 05/22/2014 08:47 PM, Reuben Thomas wrote:
> > It would be helpful to this addle-pated individual if du would output the
> > same units as it accepts as SIZE inputs, so that one could more readily
> > tell whether one was getti
On 23 May 2014 13:12, Pádraig Brady wrote:
> tl;dr
>
> You can get what you want currently by doing:
>
> du() { env du -B1 "$@" | numfmt --to=iec-i --suffix=B; }
>
Thanks very much, that's certainly good enough for me.
My understanding of the rest of what you wrote is that fixing the
inco
In the info page for csplit, it mentions LINE under the `N' pattern where
presumably it means N (there's no other reference to a LINE parameter on
that page).
--
http://www.mupsych.org/~rrt/ | wisdom, n. knowing when to be foolish
___
Bug-coreutils m
I'm not sure if this is a bug, but
printf "%c" 49
prints
4
instead of what I'd expect, which is
1
(ASCII 49)
Taken literally, I suppose this could be construed as "converting the
argument to the correct type", since the argument 49 is really a string,
but is seems a bit perverse, and it's ce
When I run uniq from coreutils 5.0 with LANG=en_GB.UTF-8 on a glibc 2.3.2
system on a file which (I think) is not valid UTF-8, I get a confusing
result: the two lines in the file are identical, but uniq prints them
both, and returns an exit code of 0. If I run
LANG=C uniq
I get the expected sing
> Can you please try coreutils-5.2.0? It has some patches in this area.
Yes, that fixes it. Thanks.
--
http://www.mupsych.org/~rrt/ | historian, n. a broad-gauge gossip (Bierce)
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/m
rm(1) has a synopsis in which "FILE…" is a mandatory argument; the info
page (correctly) has it optional. (Alternatively, you could add a separate
synopsis line for -f, which seems to be the only flag that makes the FILE
argument optional.)
--
http://rrt.sc3d.org
On 29 November 2012 at 19:16, Pádraig Brady wrote:
> On 11/29/2012 07:03 PM, Reuben Thomas wrote:
>
>> On 29 November 2012 15:35, Pádraig Brady wrote:
>>
>>
>>> I definitely think this is worthwhile.
>>>
>>>
>> Great!
>>
>>
On 16 May 2016 at 14:42, Pádraig Brady wrote:
> On 16/05/16 14:15, Reuben Thomas wrote:
>
>>
>> Did this get anywhere?
>>
>
> Nothing public unfortunately.
Are there difficulties one might be able to help with?
--
http://rrt.sc3d.org
On Mon, 16 May 2016 at 15:42, Pádraig Brady wrote:
>
> I just don't have the time at present to complete this.
>
> I did implement ACID file replacement using POSIX APIs a while ago in:
> https://github.com/pixelb/crudini
> The commit messages there have details on fsync()ing requirements etc.
>
On Fri, 23 May 2014 at 15:02, Reuben Thomas wrote:
> On 23 May 2014 13:12, Pádraig Brady wrote:
>
>> tl;dr
>>
>> You can get what you want currently by doing:
>>
>> du() { env du -B1 "$@" | numfmt --to=iec-i --suffix=B; }
>>
>
51 matches
Mail list logo
