Hi,
this is probably all correct behavior as it is right now (coreutils 6.9):
$ date +%s
120433
$ TZ=GMT date +%s
120433
$ TZ=PDT date +%s
120433
but is there actually a way to do
$ TZ=anything date +%s -d "`date '+%Y-%m-%d %H
On Feb 29 2008 14:20, Bob Proulx wrote:
>Right. I assume you were *very fast* typing in that data and that
>seconds did not move on while you were doing it. :-) I get the point
>though. That value is a timezone independent value.
>
>> but is there actually a way to do
>>
>> $ TZ=anything
On Feb 29 2008 15:26, Bob Proulx wrote:
>>
>> echo $[`date +%s` % 86400];
>
>Note that the $[expression] syntax is deprecated and is scheduled for
>removal from a future version of the shell. Please convert to using
>the now standard $((expression)) syntax.
>
> echo $(( $(date +%s) % 86400
https://bugzilla.novell.com/show_bug.cgi?id=381873
Forwarding this because it is a GNU issue, not specifically a Novell one.
I reproduced this myself with the latest coreutils from git
(BTW: You might want to repack that repo, "counting objects" during the
clone was rather slow in the initial co
On Wednesday 2008-05-07 13:11, Pádraig Brady wrote:
>
>Now that is a _lot_ of extra time. libiconv could probably be
>made more efficient. I've never actually looked at it.
>However wc calls mbrtowc() for each multibyte character.
>It would probably be a lot more efficient to use mbstowcs()
>to co
By default, ls highlights setuid/setgid/etc. files with a color, but
there is no way to restore the old (coreutils 5.x?) behavior, i.e.
that the setuid file gets the same color as it would when not having
suid.
Assume an /etc/DIR_COLORS of:
NORMAL 0
FILE 0
EXEC 1;31 # bri
Do not hardcore any colors because that makes it harder to override
them (see previous patch).
---
src/dircolors.hin | 127 --
1 file changed, 127 deletions(-)
Index: coreutils-6.11/src/dircolors.hin
==
I think ls should not hardcode _any_ colors.
---
src/ls.c | 18 +-
tests/ls/color-dtype-dir |6 +++---
2 files changed, 12 insertions(+), 12 deletions(-)
Index: coreutils-6.11/src/ls.c
===
---
If the symlink points to a directory, take it as one when sorting
by directory is turned on.
---
src/ls.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
Index: coreutils-6.11/src/ls.c
===
--- coreutils-6.
On Saturday 2008-06-21 19:37, Jim Meyering wrote:
>To make it red instead of green, you might use this:
>
>$ LS_COLORS='ex=1;31:sg=' ./ls -log --color
This does not seem to work everywhere:
$ LS_COLORS="" ./ls --color -ld /tmp
drwxrwxrwt 14 root root 4096 Jun 21 20:00 /tmp [the usual 30;42]
mkdir -p does not play nice when the directory (/home in this case) has
a default ACL.
22:57 Kiste:/home # strace -e mkdir mkdir test1
mkdir("test1", 0777)= 0
22:57 Kiste:/home # strace -e mkdir mkdir -p test2
mkdir("test2", 0755)= 0
22:57 Kiste:/home # l
On Saturday 2008-07-26 00:31, Paul Eggert wrote:
>
>> Using 0755 is what I deem the bug, and 0777 is what I think is
>> correct.
>
>But mkdir -p also invokes umask, so the two should be equivalent.
>Here's the behavior I see with coreutils 6.12 on Debian stable (no ACLs):
>
> $ umask
> 0022
>
On Tuesday 2008-10-14 10:17, Jim Meyering wrote:
>>
>> --- ls.c.1 2008-10-14 12:24:39.60505 +0400
>> +++ ls.c 2008-10-14 12:25:48.985396400 +0400
>> @@ -538,7 +538,7 @@
>>{
>> { LEN_STR_PAIR ("\033[") }, /* lc: Left of color sequence */
>> { LEN_STR_PAIR ("m") }
Hi,
I noticed that my coreutils's chroot manpage is not in section 8, though
the chroot operation is generally only available to the superuser (at
least on Linux).
coreutils version 6.11. The "problem" (which may not be one) is also
present in the latest git snapshot.
__
Hi,
fyi, commit c7e971bee0aa606eef67c0f77711e3feeb5025f3 added:
+...@example
+...@samp{b} =>512 ("blocks")
+...@samp{kb} => 1000 (KiloBytes)
+...@samp{k} => 1024 (KibiBytes)
+...@samp{mb} => 1000*1000 (MegaBytes)
+...@samp{m} => 1024*1024 (MebiBytes)
On Tuesday 2008-10-14 16:57, Jan Engelhardt wrote:
>On Tuesday 2008-10-14 10:17, Jim Meyering wrote:
>>>
>>> --- ls.c.1 2008-10-14 12:24:39.60505 +0400
>>> +++ ls.c2008-10-14 12:25:48.985396400 +0400
>>> @@ -538,7 +538,7 @@
>>>{
>&
Hi,
it always puzzled me - why do projects require automake "1.10a" when
there is no such version on the GNU servers? Perhaps 1.10.1 was
intended?
>> http://ftp.gnu.org/gnu/automake/?C=M;O=D
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
ht
On Wednesday 2008-12-24 15:26, Eric Blake wrote:
>According to Jan Engelhardt on 12/24/2008 7:24 AM:
>> Hi,
>>
>>
>> it always puzzled me - why do projects require automake "1.10a" when
>> there is no such version on the GNU servers? Perhaps 1
On Tuesday 2008-12-30 21:47, Jim Meyering wrote:
>
>Thanks for the follow-up.
>I've just tried to reproduce the problem using the latest
>version of ls, invoked from a linux vt, then xterm, aterm and rxvt
>windows. Each time, I did this in an empty directory:
>
> seq 100|xargs touch; touch z.foo
On Wednesday 2008-12-31 13:06, Jim Meyering wrote:
>>
>> You have to use a long filename (not just z.foo) that wraps in the
>> terminal. See the video at
>> http://jengelh.medozas.de/files/coreutils7ls.ogv for details.
>> Version used was v7.0-114-g921feef.
>>
>> Standard ./configure and (slightly
On Saturday 2008-06-21 19:37, Jim Meyering wrote:
>Jan Engelhardt wrote:
>> By default, ls highlights setuid/setgid/etc. files with a color, but
>> there is no way to restore the old (coreutils 5.x?) behavior, i.e.
>> that the setuid file gets the same color as it would wh
ver, it did not seem to have made it into the official source tree,
so I am asking whether it(*) could be added, now maybe?
(*)Of course, a patch for a more recent coreutils, e.g.
http://linux01.org:/f/hxtools/patches/ls-5.2.1-dirfirst.diff
Jan Engelhardt
--
Gesellschaft f
Hello list,
since there have been no replies to the discussion about sort-dirs-first
option, I repost this feature request and would like to see this feature being
included in the mainstream coreutils.
http://lists.gnu.org/archive/html/bug-coreutils/2004-08/msg00113.html
Jan Engelhardt
> find all directories bigger than 3G?
(with recursion:)
find / -type d -print0 | xargs -0 du --app -s | sort -gr | less -S
Works wonders. At least, for me.
Finds cumulative sizes, enough to spot big dirs.
Jan Engelhardt
--
___
Bug-coreut
uot;mv" and "rm" programs
however, do The Right Thing, along the lines of
case 'f':
x.interactive = false;
"cp" on the other hand is missing this. The following patch adds it in.
Signed-off-by: Jan Engelhardt <[EMAIL PROTECT
On Mar 11 2007 22:35, Andreas Schwab wrote:
>>
>> by default, coreutils cp will overwrite a file. Hence I put in
>>
>> alias cp='/bin/cp -i'
>>
>> into the system-wide profile. However, users wishing to override the
>> now-system-default of interactivity cannot do so because -f does not
>>
Cc'ed bug-coreutils.
The following bug affects at least:
coreutils 6.4 (used in opensuse 10.2 - open a bug report here)
coreutils 6.9
On May 12 2007 15:16, J G Miller wrote:
>From: J G Miller
>To: Jan Engelhardt
>Subject: re: chmod octa
On May 12 2007 12:07, Eric Blake wrote:
>
>According to Jan Engelhardt on 5/12/2007 8:50 AM:
>> Cc'ed bug-coreutils.
>> The following bug affects at least:
>> coreutils 6.4 (used in opensuse 10.2 - open a bug report here)
>> coreutils 6.9
>>
>>
havior with setuid and setgid bits.
>> Remove misleading implication about leading zero. Problem
>> reported by Jan Engelhardt in
>> <http://lists.gnu.org/archive/html/bug-coreutils/2007-05/msg00134.html>.
>
>Thanks, Paul!
>I've applied th
Hi,
=== Patch begins here ===
By default, ls highlights setuid/setgid/etc. files with a color, but there
is no way to restore the old (coreutils 5.x?) behavior, i.e. that the
setuid file gets the same color as it would when not having suid.
Assume an /etc/DIR_COLORS of:
NORMAL 0
Hi,
chown(1) has a -h option by which it affects symlinks directly rather
than the pointed-to file. The bonus side effect is that the
pointed-to files don't get changed in any way, which is kinda welcome
if you attempt to "fix" permissions/ownership in a directory where an
evil user could create
On Friday 2011-12-16 18:30, Bob Proulx wrote:
>
>chmod -R [does not] by default dereference[s] symlinks.
It does not? Oh, in that case the report may be closed.
This behavior is however inconsistent with what chown (and many other
tools) do by default though.
Hi.
Using cp, one can for example execute
cp foo/bar.txt /tmp/foo/
to have /tmp/foo/bar.txt in place after a successful copy operation,
provided the directory /tmp/foo exists. If it does not, one has to mkdir
it beforehand naturally. I thought that using `install -D` would remedy
thi
33 matches
Mail list logo
