Re: chown regression from coreutils 5.2.1 for execute-only files

Following up on my own email it appears that an lchown-based approach doesn't work as I'd hoped, because fts doesn't easily tell me whether the file we're visiting is actually a symlink. However, I can fix the bug reported in

Re: date -d and the leapsecond

"Dr. David Alan Gilbert" <[EMAIL PROTECTED]> writes: > Now as I understand it the Unix time can't represent the > leapsecond in the seconds-since-epoch, but if that is a valid > UTC date then should it really accept it as input ? Yes, on hosts that support leap seconds. On hosts that don't one c

Re: date bug

William Johnson <[EMAIL PROTECTED]> writes: > I have run this script on my linux router and in cygwin. > In both cases, the date is changed from 2006 to 2005. The output is correct. %G corresponds to %V, and so Sunday January 1 is considered to be in the previous year (2005, in this case). You

Re: date bug

On Mon, 2 Jan 2006, William Johnson wrote: I have run this script on my linux router and in cygwin. In both cases, the date is changed from 2006 to 2005. <---> set Time_Stamp="01-Jan-2006 21:22:23" echo "$Time_Stamp" set MyDate=`date --date="$Time_Stamp" "+%G-%m-%d %T %a"` echo "$MyDat

Re: [ program

Except that '[' is a built-in with most shells today. But for older shells it was an external command. I think it is important to note that GNU [ supports more fancy things than the default GNU bash builtin; or atleast, used too... ___ Bug-coreu

Re: [ program

I was wondering if that [ program is supposed to be there, or if it's a typo. If I run info [ I get the info page for test, so I wasn't certain if they were related. They are the same, [ is for systems that don't have [ builtin into the shell. Consider the following shell expresion: if

Re: [ program

Brian Beck wrote: > After compiling the coreutils, I looked in the coreutils-5.93/src directory, > and noticed and executable named "[" doing an ls -l \[ gave me... > > -rwxr-xr-x 1 bbeck bbeck 73120 2006-01-02 16:03 [ Yes. That is normal and good. > when I tried running the file it output...

[ program

Coreutils: After compiling the coreutils, I looked in the coreutils-5.93/src directory, and noticed and executable named "[" doing an ls -l \[ gave me... -rwxr-xr-x 1 bbeck bbeck 73120 2006-01-02 16:03 [ when I tried running the file it output... ./[: missing `]' on a whim I ran the program w

date -d and the leapsecond

Hi, I've noticed that there is a change in behaviour where in recent CVS, date -d will not accept a second count of 60 - i.e. date -d "Sat Dec 31 23:59:60 UTC 2005" gives 'invalid date' - where as the older 5.2.1 accepts it (and gives midnight Jan 1). Now as I understand it the Unix time can't

Re: problem with split

* John Joseph Bachir ([EMAIL PROTECTED]) wrote: > it seems that on os x, split can only make files as big as 600 megs or > so. here is the command i am using: > > split -b4700m myFile.tar.gz myFile.tar.gz_ ; > > Which should be about DVD sized chunks. But the files come out a > little over 600 me

date bug

I have run this script on my linux router and in cygwin. In both cases, the date is changed from 2006 to 2005. <---> set Time_Stamp="01-Jan-2006 21:22:23" echo "$Time_Stamp" set MyDate=`date --date="$Time_Stamp" "+%G-%m-%d %T %a"` echo "$MyDate" <---> The problem disappears on January 2.

Re: problem with split

On 1/2/06, Paul Eggert <[EMAIL PROTECTED]> wrote: > Perhaps you're running an old version of split? "split --version" > should tell you. If it's before version 5.0.1 you need to upgrade, to > fix that bug. The current version is 5.93. > > ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.93.tar.gz >

Re: point to "info coreutils cmd" instead of "info cmd" in manpage

Ideally, info would be fixed to allow an exact-match, rather than the current, first-match approach. Or better yet, extending --show-options so you can pass a program to it. Say, info --show-options pr coreutils. ___ Bug-coreutils mailing list B

Re: point to "info coreutils cmd" instead of "info cmd" in manpage

"Theodoros V. Kalamatianos" <[EMAIL PROTECTED]> wrote: > On Sat, 31 Dec 2005, The Wanderer wrote: > >> Entering 'info mv' brings up an info interface to the exact same >> page, including the same suggestion at the bottom. This is probably >> more a Debian issue than a coreutils one, though. > > I t

Re: problem with split

John Joseph Bachir <[EMAIL PROTECTED]> writes: > split -b4700m myFile.tar.gz myFile.tar.gz_ ; > > Which should be about DVD sized chunks. But the files come out a > little over 600 megs each. Perhaps you're running an old version of split? "split --version" should tell you. If it's before versi

problem with split

it seems that on os x, split can only make files as big as 600 megs or so. here is the command i am using: split -b4700m myFile.tar.gz myFile.tar.gz_ ; Which should be about DVD sized chunks. But the files come out a little over 600 megs each. thanks john __

Re: env (GNU coreutils) 5.93 patch

> If I crick doing "env" hacking, are you able to create a new command? You are free to hack env, since it is open source, and you are free to write your own commands. However, it is very doubtful that coreutils will ever include your hacks, or adopt your proposed 'exe' utility, since no one else

Re: env (GNU coreutils) 5.93 patch

[EMAIL PROTECTED] (Bob Proulx) writes: > On what systems is env located in /bin/env? The normal location is in > /usr/bin/env. POSIX doesn't specify the location for env, so either location conforms to POSIX. On Solaris 10, the standard location is /usr/xpg4/bin/env. (/usr/bin/env doesn't confo

chown regression from coreutils 5.2.1 for execute-only files

The chown problem I mentioned in the last paragraph of still remains. My initial reaction is to do something for chown that is similar to what I just installed fro chmod; this would prefer lchown to chown. lchown is not quite