modechange.c decrements a pointer past the start of the string,
which is theoretically a no-no. I installed this:
2004-09-23 Paul Eggert <[EMAIL PROTECTED]>
* lib/modechange.c (mode_compile): Don't decrement a pointer that
points to the start of a string, as the C Standard says
Martin Siegert <[EMAIL PROTECTED]> writes:
> statfs("/home1", 0xbfffeee0)= -1 EOVERFLOW (Value too large for defined
> data type)
This looks very much like a problem with that kernel or its NFS interface.
If statfs fails, that would explain why df is failing.
__
Hans Ecke <[EMAIL PROTECTED]> writes:
> Is there any way that chmod could first see if the requested status
> change has already been fulfilled, and skip files where it would not
> change anything?
Offhand I don't see why not. POSIX allows this behavior.
> I can see that this would slow chmod d
Paul,
Unfortunately I can not offer to do this myself (a.k.a. put up or shut
up). I just don't have the time. If you (or somebody else) can do it I'd
very much appreciate it. Otherwise, thanks a lot for your work on the
coreutils.
Hans
--
Hans Ecke [EMAIL PROTECTED] / [EMAIL P
In adding chmod test cases inspired by a recent Open Group email from
Glenn Fowler, I noticed that chmod had some bogus behavior for cases
like "chmod -r -w file":
$ chmod -r -w file
chmod: invalid character `w' in mode string `-w'
chmod need not support -r -w, but it should behave better whe
Sorry, my previous email forgot to include the new file tests/chmod/usage.
Here it is:
#!/bin/sh
# Verify that chmod works correctly with odd option combinations.
if test "$VERBOSE" = yes; then
set -x
chmod --version
fi
. $srcdir/../lang-default
pwd=`pwd`
tmp=equals.$$
trap 'status=$?; cd $
Another solution is to assume that the current buffer and the one new line
have used the same ls options and contain the same number of space-separated
fields. Based on this, you can add spaces so as to align the fields in the
new line to the field of the other lines.
That would b
> I think a better solution is if we can turn off the new "feature"
> of adapting the column widths to the data.
One way would be to extend --format to allow fairly arbitrary formats
that can specify column widths. For example, Emacs could do this:
ls --format='%11m %2l %8o
It maybe a bit less work, but it's certainly not "better" -- without the
auto-adjustment feature, it "simply" would use absurdly large amounts of
whitespace _just in case_ a file happens to be hundreds of gigabytes in size
and have thousands of links.
If ls does what ls used to do,
> Another solution is to assume that the current buffer and the one new
> line have used the same ls options and contain the same number of
> space-separated fields. Based on this, you can add spaces so as to
> align the fields in the new line to the field of the other lines.
> Th
Here's a proposed patch to implement RMS's request to support Emacs
dired fixed-width columns. It's a bit of a quick hack, and is
therefore undocumented. A better long-term approach is to allow
arbitrary formats, but that'd take more work (notably in the
documentation) and this is simpler.
This
11 matches
Mail list logo
