On Sun, Apr 06, 2008 at 12:56:19PM -0400, Bo Borgerson wrote:
On Sun, Apr 6, 2008 at 12:35 PM, Jim Meyering <[EMAIL PROTECTED]> wrote:
Thanks.
That feels pretty kludgy. I hope we end up with something cleaner.
Yeah, I suppose so. Short of including `translations' for English,
though, what'
On Fri, Sep 12, 2008 at 09:51:04PM +0200, Jim Meyering wrote:
That sounds like a good reason to retain the behavior you've come to
value, even if it's not guaranteed or portable, but only via a new
option. Then we can still change the default to be more efficient.
Why on earth would we want to
On Fri, Oct 24, 2008 at 09:19:07AM -0400, Mike Edenfield wrote:
Speaking as a fairly new SELinux user/admin, having a "."
next to every file in my ls output is just as useful or
non-useful as having a "+" next to them, so does it really
buy anything?
It buys something if you're unaware that s
On Tue, Feb 08, 2005 at 03:39:05PM +, James Youngman wrote:
No.The POSIX standard (in a non-normative section) says :-
| The unit for the st_blocks member of the stat structure is not defined
| within IEEE Std 1003.1-2001. In some implementations it is 512
| bytes. It may differ on a file s
On Tue, Feb 08, 2005 at 01:56:00PM -0800, Paul Eggert wrote:
OK, thanks, I installed this (revised) patch into coreutils, which I
hope addresses that problem.
No, if you're going to use the statvfs block size you need to pull the
other numbers from statvfs also. IOW, just add another flag (-F?) to
On Fri, Jun 24, 2005 at 11:17:20AM -0600, you wrote:
The second option that I recommend is to deprecate this option
entirely and remove it from the code base.
I think it's safe to say that a number of these utilities have gotten
more flags than they strictly need. Pruning may be a good thing.
On Tue, Nov 15, 2005 at 11:42:12AM +0100, Jim Meyering wrote:
With stat, a specified format is no longer automatically newline terminated.
If you want a newline at the end of your output, append `\n' to the format
string.
Hmm. I don't know if I like this change--it really screws with
compata
On Tue, Nov 15, 2005 at 12:27:57PM +0100, Jim Meyering wrote:
I do see your point of view, since the `stat' program doesn't feel
very new, now. But back when I made the change, it *was* relatively new.
Not in debian. I'll have to think about whether I want the debian
package to maintain compat
On Tue, Nov 15, 2005 at 11:42:12AM +0100, Jim Meyering wrote:
Unfortunately, no one reported the problem before this.
Which IMO suggests that nobody cares for the new behavior, whereas we
have a demonstrable dependency on the old behavior. Between debian &
fedora & rhel I'd say that there's a f
On Tue, Nov 15, 2005 at 03:14:27PM +0100, Jim Meyering wrote:
But there *is* a way. It's just that the portable solution
doesn't fit on one line:
That falls into the "truely hideous" category, imo. :)
Mike Stone
___
Bug-coreutils mailing list
Bug-
x27;s in a readme file without having
to strip the descriptive text.
--
Michael Stone
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
On Mon, Sep 07, 2009 at 05:15:58PM +0200, Jim Meyering wrote:
Giuseppe Scrivano wrote:
This patch changes `tail' to handle stdin separately from inotify
events, similar to what we are already doing when a --pid is specified.
This sounds good in principle, but it's too invasive for 7.6.
I'll lo
9-03-29 13:43:41.0 -0400
+++ coreutils-7.2/src/stty.c2009-04-07 21:11:35.096288547 -0400
@@ -279,10 +279,18 @@
{"cr0", output, SANE_SET, CR0, CRDLY},
#endif
#ifdef TABDLY
+#ifdef TAB3
{"tab3", output, SANE_UNSET, TAB3, TABDLY},
+#endif
+#ifdef TAB2
{"
On Thu, Jan 14, 2010 at 11:15:48AM +0800, jida...@jidanni.org wrote:
So, that's why I suggested saying __both__ methods.
But you already closed the bug before reading to the end.
No, I read all the way to the end. I don't think the boilerplate needs
to be any longer than it is.
Mike Stone
It seems that touch -a does update ctime on btrfs, invalidating one of
the assumptions behind this test and causing it to fail.
Mike Stone
On Sun, Jan 17, 2010 at 09:59:46AM +0100, Andreas Schwab wrote:
Michael Stone writes:
It seems that touch -a does update ctime on btrfs, invalidating one of the
assumptions behind this test and causing it to fail.
Did you mean "does not update ctime"?
Yes. My eyes are starting t
On Sun, Jan 17, 2010 at 10:08:23AM -0500, Michael Stone wrote:
But then I also have a build log
(https://buildd.debian.org/fetch.cgi?&pkg=coreutils&ver=8.1-1&arch=amd64&stamp=1261006367&file=log)
with a different failure, which is what I thought I'd duplicated last
On Tue, Feb 09, 2010 at 05:33:04PM +0100, Petr Salinger wrote:
the current coreutils fails to build on GNU/kFreeBSD.
Under 7.2 kernel 9 test fails,
under 8.0 kernel 1 test fail.
The failure under 7.2 kernel is due to limitation
of chroot and bind mounts, it is solved in 8.0 kernel.
Cool. I fin
Figures that I get completely different results with kfreebsd 8 kernel.
(Presumably the install test isn't an issue because my user doesn't have
multiple groups--will still look at that.)
tests/tail-2/inotify-hash-abuse2 fails, which I'm not even sure is
relevant. (No inotify; maybe have the t
On Wed, Feb 10, 2010 at 11:19:27PM +, Pádraig Brady wrote:
That test should pass irrespective of inotify availability.
I've spun it for 20 mins now on linux with inotify disabled without issue:
while true; do
(cd tests && make check TESTS=tail-2/inotify-hash-abuse2 VERBOSE=yes) || break
do
On Wed, Aug 16, 2006 at 08:18:27AM +0200, Jim Meyering wrote:
What version of Linux is that?
2.6.17
From the name of the directory, it's probably a tmpfs file system.
actually it's xfs. it's inside a pbuilder chroot, so the mtab is going
to be completely bogus (I think mount would report /
On Wed, Aug 16, 2006 at 11:38:28AM +0200, Jim Meyering wrote:
Ok. Then I'll use a more robust test for file system type.
This also relaxes the test to run if "." is an ext2 file system.
Does this patch solve the problem?
looks like it
Mike Stone
_
On Thu, Oct 19, 2006 at 11:29:23AM +0200, Jim Meyering wrote:
My motivation for making this change is mainly security.
The paranoid user of chown (usually root) should not have to imagine
that a numeric user name argument like "1000" might be interpreted as
a name and mapped to "0".
Can anyone p
On Sat, Jan 26, 2008 at 07:23:08PM +0100, Jim Meyering wrote:
I know Bob Proulx is already subscribed there.
Some of the traffic would not be interesting, i.e., a message
announcing that a bug is closed, or tagged -- but those are easy to skip.
Overall, I think it would be better for both Debian
On Sun, Jan 27, 2008 at 01:34:36PM -0600, Karl Berry wrote:
What this report really says to me is that the dir file was not
correctly created by the Debian (or whatever) installation process.
Oh, without a doubt. The debian install-info routine (IIRC) predates the
gnu install-info, and hasn't
On Sun, Jan 27, 2008 at 09:30:51PM +0100, Jim Meyering wrote:
Yes, that is the root of the problem.
It came down to a dispute about which of two install-info
programs should be installed. I'm amazed that it's lasted
so long (it seems it's been at least two years, now).
I don't think it's a dis
On Sun, Jan 27, 2008 at 06:51:54PM -0600, Karl Berry wrote:
mstone> The debian install-info routine (IIRC) predates the
gnu install-info,
That wasn't my understanding, but I never actually researched it. I was
not aware of any Debian ii at the time that rms wrote GNU ii (I was
maintaini
I can readily duplicate this bug report on a 2.6.24-rc7 kernel by
running `ls -l /proc/sys/fs/inotify`
Kernel bug? libselinux bug? Documentation bug?
I suppose coreutils should check that the returned context is non-NULL.
It looks like the debian 5.97-5.3 selinux patch (derived from redhat)
On Wed, Sep 21, 2011 at 10:18:47AM +0200, Michel Dänzer wrote:
The test fails because it doesn't pass $CFLAGS to the compiler. The attached
patch fixes this, so the test is skipped as expected.
The point wasn't to skip the test, it was to fix the bug. :-)
Unfortunately, the CFLAGS change doesn
On Thu, Sep 22, 2011 at 11:58:37AM +0200, Michel Dänzer wrote:
The skip message contains 'this test runs only on systems with [...]
long double != double', which isn't satisfied with -mlong-double-64, is
it?
See the output samples; the prior version worked fine at this boundary,
the new versio
On Fri, Nov 01, 2013 at 01:46:33AM +0530, Jeffrin Jose wrote:
i have patched debian source from sid for file
uname.c for debian coreutils.
For what it's worth, I stand by what I wrote in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193170 in 2007 and
still don't see any reason for -i and
On Mon, Sep 08, 2014 at 06:10:35PM -0600, Bob Proulx wrote:
But I think in recent years the install-info problems have been fixed.
Perhaps we don't need to do any of this anymore? Or perhaps finally
getting to the canonical (FILENAME)NODE-WITHIN-FILE form we have
finally arrived at the end and s
On Tue, Sep 09, 2014 at 03:31:35PM +0100, Pádraig Brady wrote:
It's useful to many, but I agree most don't bother with it
due to the awkward non intuitive default info reader _interface_
(though pinfo is a bit better in that regard).
Right. I've heard the argument for 15 years that info docs ar
I'm looking for some information before I run too far down this rathole.
Currently cp --preserve=all will attempt to preserve both the unix modes and
any ACL on a file. This seems to be working entirely as expected with a
linux NFS4 client & server. If I attempt the same using a solaris
server,
On Tue, Jun 23, 2015 at 05:39:14PM +0100, Pádraig Brady wrote:
There have been recent changes in this area,
so we need to know the version to help determine
if this is a regression or was always an issue.
8.23, 8.13
On Tue, Jun 23, 2015 at 07:05:43PM +0200, Andreas Grünbacher wrote:
I assume
On Tue, Jun 23, 2015 at 08:22:44PM +0200, Andreas Grünbacher wrote:
Somewhat. The "system.nfs4_acl" attribute is nfs specific though: its
format isn't
well suited for other file systems. Adding support to gnulib would only make
copying permissions on nfs work, not across different file system typ
On Tue, Jul 17, 2018 at 01:25:59AM -0700, L A Walsh wrote:
I am not suggesting handing out alternates when you have a
choice. I'm suggesting doing something useful in a case where there are
no alternates and no downsides. If you can come up with a case where
a symlink to a directory wou
On Wed, Jul 18, 2018 at 03:23:59AM -0700, L A Walsh wrote:
In the case of creating a link to a directory there is
no choice in creating a "working solution". If you want a link there,
it HAS to be a symlink. That the user would bother to
use the 'ln' (link) command in the first place
the
old behavior. I am reluctant to do so as that will likely lead to
divergent behavior between distributions, but breaking scripts without a
compelling reason is also not good. I would encourage coreutils to
reconsider the change and finding a non-breaking way forward.
Michael Stone
that's because it has not yet been widely deployed, which
makes now the time to fix it.
Michael Stone
On Fri, Dec 15, 2023 at 11:21:06AM -0800, Paul Eggert wrote:
Stlll, Pádraig gave a reasonable summary of why the change was made,
despite its incompatibility with previous behavior. (One thing I'd add
is that the FreeBSD behavior is inherently less race-prone.) It seemed
like a good idea at the
On Sun, Dec 17, 2023 at 12:34:11AM -0800, Paul Eggert wrote:
On 2023-12-16 13:46, Bernhard Voelker wrote:
Whether the implementation is race-prone or not is an internal thing.
I wasn't referring to the internal implementation. I was referring to
cp users. With the newer Coreutils (FreeBSD) be
On Sun, Jan 28, 2024 at 11:14:14PM -0800, Paul Eggert wrote:
I'm not sure reverting would be best. It would introduce more
confusion, and would make coreutils incompatible with FreeBSD again.
Reverting makes more sense than the current situation. I do not
understand why you seem to value FreeB
On Mon, Jan 29, 2024 at 04:11:05PM +, Pádraig Brady wrote:
You've introduced a silent incompatibility and I'm trying to find some
way to make that clear. If upstream would provide a better solution I
would certainly use it. I have despaired of there being such since your
attitude thus far see
On Mon, Feb 17, 2025 at 12:28:03AM +0100, Vincent Lefevre wrote:
No data for xterm. Other terminals are affected too, such as
GNOME Terminal.
Yes, much of the data from the old utmp is simply not there. A sane
transition would deprecate utmp in one release while adding a
replacement, then rem
On Sun, Feb 16, 2025 at 07:05:13PM +0100, Vincent Lefevre wrote:
No, w(1) is broken (at least in sid). See the difference between
"who" and "w" with systemd 256.7-1, i.e. before the upgrade of
systemd that removed utmp support:
That's because someone decided to suddenly remove an interface whic
46 matches
Mail list logo
