Re: [Bug-gnulib] vasnprintf.m4 patch for Solaris 2.5.1 wcslenproblem

[Bruno Haible]

Paul Eggert wrote:

> > wcslen  ../lib/libfetish.a(vasnprintf.o) 
> > (symbol belongs to implicit dependency /usr/lib/libw.so.1)
>
> This problem arises because Solaris 2.5.1 puts the following functions
> into /usr/lib/libw.so.1, so you need to link with -lw if you use any
> of these functions:
>
>fgetwc fputwc getwc isenglish isideogram isnumber isphonogram isspecial
>iswalnum iswalpha iswcntrl iswctype iswdigit iswgraph iswlower iswprint
>iswpunct iswspace iswupper iswxdigit mbftowc putwc scrwidth towlower
>towupper ungetwc watoll wcscat wcschr wcscmp wcscoll wcscpy wcscspn
>wcslen wcsncat wcsncmp wcsncpy wcspbrk wcsrchr wcstod wcstok wcstol
>wcstoul wcswcs wcswidth wcsxfrm wctype wcwidth wscasecmp wscat wschr
>wscmp wscoll wscpy wscspn wslen wsncasecmp wsncat wsncmp wsncpy wspbrk
>wsrchr wstod wstok wstol wstoll wsxfrm

Thanks for the analysis.

>   * m4/vasnprintf.m4 (gl_PREREQ_VASNPRINTF):
>   Solaris 2.5.1 needs -lw to get the wcslen function.

Since vasnprintf.c is also used by libintl (starting from gettext-0.12.2),
this would imply making a dependency from libintl.so to libw.so, thus
slowing down all internationalized applications... I prefer the appended
patch, which I'm committing into gnulib.

> I notice that other gnulib modules use the above functions.

- In fnmatch.c it is no problem because HANDLE_MULTIBYTE is only defined
  if mbsrtowcs() is found, which is not the case on Solaris 2.5.1.
- In regex.c it is no problem because gnulib doesn't compile regex with
  MBS_SUPPORT.
- In strftime.c it is no problem gnulib doesn't compile strftime with
  COMPILE_WIDE.

Bruno



2003-08-11  Bruno Haible  <[EMAIL PROTECTED]>

* vasnprintf.c (local_wcslen): New function, for Solaris 2.5.1.
(vasnprintf): Use it instead of wcslen.

diff -c -3 -r1.4 vasnprintf.c
*** vasnprintf.c15 Jul 2003 12:42:06 -  1.4
--- vasnprintf.c11 Aug 2003 12:57:29 -
***
*** 47,52 
--- 47,70 
  # define freea(p) free (p) 
  #endif
  
+ #ifdef HAVE_WCHAR_T
+ # ifdef HAVE_WCSLEN
+ #  define local_wcslen wcslen
+ # else
+/* Solaris 2.5.1 has wcslen() in a separate library libw.so. To avoid
+   a dependency towards this library, here is a local substitute.  */
+ static size_t
+ local_wcslen (const wchar_t *s)
+ {
+   const wchar_t *ptr;
+ 
+   for (ptr = s; *ptr != (wchar_t) 0; ptr++)
+ ;
+   return ptr - s;
+ }
+ # endif
+ #endif
+ 
  char *
  vasnprintf (char *resultbuf, size_t *lengthp, const char *format, va_list args)
  {
***
*** 368,374 
  # ifdef HAVE_WCHAR_T
  if (type == TYPE_WIDE_STRING)
tmp_length =
! wcslen (a.arg[dp->arg_index].a.a_wide_string)
  * MB_CUR_MAX;
  else
  # endif
--- 386,392 
  # ifdef HAVE_WCHAR_T
  if (type == TYPE_WIDE_STRING)
tmp_length =
! local_wcslen (a.arg[dp->arg_index].a.a_wide_string)
  * MB_CUR_MAX;
  else
  # endif



___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

source code for 'df'

[Kalyan Kumar]

Hello,

 

I was wondering where I can find source code for ‘df’ command (file system disk space usage). Is there
an equivalent Unix system call?

 

Regards,

 

Kalyan






___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: "date" not validating correctly

[Bob Proulx]

ianseeks wrote:
> I have been unable to change date on my SuSE 8.2 system.  I've tried
> using the KDE utilities and they did not work

Can't you you there...

> so i tried "date --set 081313012003" on 
> the command line and got this error  "date: invalid date `081321532003'. 

Uh, --set takes a DATESTR which is a completly different format.
Please read either the man page or the info documentation for the
format of the DATESTR.  It really is quite flexible in the strings it
can parse.

  info --index-search="Date input formats" date

Something like:

  date --set '+2 minutes'

What you are wanting with your compact format is to not use the --set
option at all.  The --set option turns on a different parser for human
readable dates.

Try this instead.

  date 081321532003

> I am in the UK using the UK date format.

It does not look like 081313012003 is a UK date format to me.  For a
UK date format I would expect something like "Thu Aug 14 01:04:00 GMT
2003" but don't flame me if I got that wrong.  I just used "LANG=en_GB
TZ=GMT date" to dump that string as I grew up in the colonies.  With
the --set option you could use that type of DATESTR and not the
traditional compact form.

  date --set '13 Aug 2003 13:01:00 +'

Date without the --set option takes this documented format of the
traditional form.

  MMDDhhmm[[CC]YY][.ss]

See the online standards documentation for more details.

  http://www.unix-systems.org/single_unix_specification_v2/xcu/date.html

This format is documented on the first page of both the info page and
the man page.

  info date
  man date

> Also note the different quote marks on the error message.

Years ago the quote and back-quote were the common ways to typeset
quotation marks.  Today's computer screen fonts look different than
they did.  Not going to go there but suffice to say it is a heatedly
debated religious war as to what is the correct way to handle those.
By one viewpoint the quotes are correct for text and your screen font
is incorrect.

> I hope this is some use, and i'm not going mad.  :o)

Don't suffer though insanity.  Enjoy every minute of it.

The --set option is a GNU extension to handle human readable date
strings.  Traditional 'date' commands do not implement that
functionality.  I think the examples in the documentation are perhaps
too heavy on the extensions and not enough on the typical use!

Bob


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: possible new feature for chmod

[Alfred M. Szmidt]

   >Because the same syntax is used in other places, e.g.:
   > 
   >  install -m %-rw-rw-r-- file directory
   >  mkdir -m %drwxr-xr-x directory
   > 
   >and similarly for mkfifo and mknod.
   > 
   > Cool, I didn't know this.

   Sorry, I didn't explain myself clearly enough.  My idea was that if
   we extended the syntax this way, the same extension would apply
   to every program that parses modes.  The above syntax does not
   yet work for install and mkdir, but it would work under my proposal.

   If we used a different option, we'd need to add a separate option to
   each of the above commands.

Thanks for the clarification.



___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: possible new feature for chmod

[Alfred M. Szmidt]

   Why not fix these problems by disambiguating the syntax?  You can put
   a new character in front of the new-format mode strings.  E.g.,

 chmod %-rw-rw-r-- file

Why not fix it with a seperate option instead (which this basicly is)?
Say, --human-readable (maybe a short option could be in order) to stay
in sync with the other utilities.

  chmod --human-readable=HMODE FILE

HMODE standads for Human-readable MODE.

As for the idea, I love it!


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

vasnprintf.m4 patch for Solaris 2.5.1 wcslen problem

[Paul Eggert]

In 
Vin Shelton <[EMAIL PROTECTED]> writes:

> 1. On SunOS-5.5.1, configuring with --disable-nls, I cannot link 'who':
> 
> gcc  -g -O2   -o who  who.o ../lib/libfetish.a  ../lib/libfetish.a -lgen -lnsl 
> Undefined   first referenced
>  symbol in file
> wcslen  ../lib/libfetish.a(vasnprintf.o)  (symbol 
> belongs to implicit dependency /usr/lib/libw.so.1)

This problem arises because Solaris 2.5.1 puts the following functions
into /usr/lib/libw.so.1, so you need to link with -lw if you use any
of these functions:

   fgetwc fputwc getwc isenglish isideogram isnumber isphonogram isspecial
   iswalnum iswalpha iswcntrl iswctype iswdigit iswgraph iswlower iswprint
   iswpunct iswspace iswupper iswxdigit mbftowc putwc scrwidth towlower
   towupper ungetwc watoll wcscat wcschr wcscmp wcscoll wcscpy wcscspn
   wcslen wcsncat wcsncmp wcsncpy wcspbrk wcsrchr wcstod wcstok wcstol
   wcstoul wcswcs wcswidth wcsxfrm wctype wcwidth wscasecmp wscat wschr
   wscmp wscoll wscpy wscspn wslen wsncasecmp wsncat wsncmp wsncpy wspbrk
   wsrchr wstod wstok wstol wstoll wsxfrm
 
At the end of this message is a patch for that, which I have tested on
my Solaris 2.5.1 host.  The patch applies to both coreutils and
gnulib, so I'll CC: this to bug-gnulib.

The patch below is suboptimal, as it links every executable with -lw,
even though only 'who' needs the -lw option, since only 'who' needs
wcslen.  However, Sun stopped generating patches for Solaris 2.5.1 on
2002-09-22, so it's a dying OS version, and I don't think we need to
optimize coreutils for Solaris 2.5.1 so long as it builds and runs
correctly.  /usr/lib/libw.so.1 is part of the SUNWcsu package, so it
is a core library available on any Solaris 2.5.1 host, and we
shouldn't have to worry that it might be on the build host but not on
the run host.

I notice that other gnulib modules use the above functions.  There is
a FIXME about this in regex.m4, for example.  Quite possibly coreutils
is not using some wide-char functions that it could use on Solaris
2.5.1.  However, these problems don't prevent the coreutils build from
succeeding, so I didn't investigate this further.


2003-08-08  Paul Eggert  <[EMAIL PROTECTED]>

* m4/vasnprintf.m4 (gl_PREREQ_VASNPRINTF):
Solaris 2.5.1 needs -lw to get the wcslen function.

--- vasnprintf.m4.~1.1.~Thu Jul 10 04:23:31 2003
+++ vasnprintf.m4   Fri Aug  8 23:37:20 2003
@@ -51,6 +51,9 @@ AC_DEFUN([gl_PREREQ_VASNPRINTF],
   AC_REQUIRE([gt_TYPE_WCHAR_T])
   AC_REQUIRE([gt_TYPE_WINT_T])
   AC_CHECK_FUNCS(snprintf)
+
+  # Solaris 2.5.1 needs -lw to get the wcslen function.
+  AC_SEARCH_LIBS(wcslen, [w])
 ])
 
 # Prerequisites of lib/asnprintf.c.


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: fold -s leaves shameful wasted blanks at end of lines

[Dan Jacobson]

> "Jim" == Jim Meyering <[EMAIL PROTECTED]> writes:

Jim> Dan Jacobson <[EMAIL PROTECTED]> wrote:
>> fold -s leaves shameful wasted blanks at end of lines:
Jim> ...
>> Therefore there needs to be another switch to do away with them.

Jim> Yes.  It looks like POSIX requires that.

Jim>   # printf 'a b\n'|fold -w2 -s|cat -A
Jim>   a $
Jim>   b$

Jim> How about piping the result through a filter like this?

Jim>   perl -pe 's/[ \t]+$//'

OK, warn people thusly on the man page and I'll let you off the hook.


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: Misc Problems with coreutils-5.0.90

[Jim Meyering]

> 2003-08-08  Paul Eggert  <[EMAIL PROTECTED]>
>
>   * tests/du/basic: Ensure that a/b/F has at least 65 bytes too.

Applied.  Thanks!


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: coreutils-5.0.90 patch 1: build feedback

[Jim Meyering]

"Nelson H. F. Beebe" <[EMAIL PROTECTED]> wrote:
> I applied the patches to tests/shred/remove, src/nice.c, and
> lib/stdbool_.h in coreutils-5.0.90 and repackaged it as
> coreutils-5.0.90.1, then launched builds on just those platforms where
> build failures had previously occurred.
>
> I still get some failures:
...
> 
> Machinetype:Intel Pentium III (600 MHz);OpenBSD 3.2 GENERIC#25 i386
> Remote gcc version: gcc (GCC) 3.3
> Remote g++ version: g++ (GCC) 3.3
> Configure environment:  CC=gcc CXX=g++ LDFLAGS=-Wl,-rpath,/usr/local/lib
>
> if gcc -DHAVE_CONFIG_H -I. -I. -I..  -I.. -I. -I../lib -I../lib   -g -O2 -MT nice.o 
> -MD -MP -MF ".deps/nice.Tpo" \
>   -c -o nice.o `test -f 'nice.c' || echo './'`nice.c; \
> then mv -f ".deps/nice.Tpo" ".deps/nice.Po"; \
> else rm -f ".deps/nice.Tpo"; exit 1; \
> fi
> In file included from nice.c:29:
> /usr/include/sys/resource.h:60: error: field `ru_utime' has incomplete type
> /usr/include/sys/resource.h:61: error: field `ru_stime' has incomplete type
> make[3]: make[3]: Leaving directory `/local/build/coreutils-5.0.90.1/src'

Hi Nelson,

Thanks again for all your testing!
I've fixed this with the following patch relative to coreutils-5.0.90:

* src/nice.c [!NICE_PRIORITY]: Include  after
system.h so the types from time.h and sys/time.h are available.
It appears that this is necessary for OpenBSD, NetBSD, and
Darwin 6.5 (MacOS 10.2.5).  Reported by Nelson Beebe.

Index: src/nice.c
===
RCS file: /fetish/cu/src/nice.c,v
retrieving revision 1.67
retrieving revision 1.69
diff -u -p -h -u -r1.67 -r1.69
--- src/nice.c  23 Jul 2003 07:29:54 -  1.67
+++ src/nice.c  10 Aug 2003 17:50:11 -  1.69
@@ -24,11 +24,15 @@
 
 #include 
 #include 
+
+#include "system.h"
+
 #ifndef NICE_PRIORITY
+/* Include this after "system.h" so we're sure to have definitions
+   (from time.h or sys/time.h) required for e.g. the ru_utime member.  */
 # include 
 #endif
 
-#include "system.h"
 #include "error.h"
 #include "long-options.h"
 #include "posixver.h"


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: date(1) treats TZ '' differently from unset

[Paul Eggert]

Ed Avis <[EMAIL PROTECTED]> writes:

> On a system where local time is +0100:
> 
> % (unset TZ; date +%z)
> +0100
> % (TZ= date +%z)
> +
> 
> Are you sure this is correct?

This is a C library issue, not a coreutils issue, since coreutils
simply repeats what the C library tells it.

In many C libraries, TZ='' is equivalent to TZ='GMT0' or TZ='UTC0',
and that's the behavior you're observing.  An unset TZ is equivalent
to a system-supplied default, typically the local time where the host
is physically located.


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: Misc Problems with coreutils-5.0.90

[Paul Eggert]

Vin Shelton <[EMAIL PROTECTED]> writes:

> + diff -u out exp 
> --- out   2003-08-07 13:37:17.441967000 -0400
> +++ exp   2003-08-07 13:37:17.484972000 -0400
> @@ -1,9 +1,9 @@
> -0a/b/F
> -4a/b
> -8a
> +4a/b/F
> +8a/b
> +12   a
>  ===
> -0a/b/F
> -4a/b
> +4a/b/F
> +8a/b
>  4a
>  ===
> -8a
> +12   a

I happen to have a Network Appliance and Solaris 8 box, and looked
into this.  Here is a patch.

2003-08-08  Paul Eggert  <[EMAIL PROTECTED]>

* tests/du/basic: Ensure that a/b/F has at least 65 bytes too.

--- basic.~1.10.~   Fri Mar 28 04:55:04 2003
+++ basic   Fri Aug  8 15:50:31 2003
@@ -19,11 +19,11 @@ framework_failure=0
 mkdir -p $tmp || framework_failure=1
 cd $tmp || framework_failure=1
 mkdir -p a/b d d/sub || framework_failure=1
-printf 'make-sure-the-file-is-non-empty\n' > a/b/F || framework_failure=1
 
 # Ensure that these files contain more than 64 bytes, so that we don't
 # immediately disqualify file systems (e.g., NetApp) on which smaller
 # files take up zero disk blocks.
+printf '%*s' 65 make-sure-the-file-is-non-empty > a/b/F || framework_failure=1
 seq --format=%100g 1 90 | head --bytes=4k > d/1
 cp d/1 d/sub/2
 


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

bug in sort

[Samuel Irlapati]

/home/irlapati>ls | sort --month-sort
sort: sort.c:1770: getmonth_mb: Assertion `mblength != (-1) && *wpp == ((void *)0)' failed.
Aborted
/home/irlapati>

/home/irlapati>uname -a
Linux Genesis 2.4.20 #1 Sat Apr 12 22:17:38 EDT 2003 i686 athlon i386 GNU/Linux
/home/irlapati>


I am running Redhat 9.





-- 
Sincerely,
Samuel Irlapati








___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: bug in sort

[Paul Eggert]

Samuel Irlapati <[EMAIL PROTECTED]> writes:

> sort: sort.c:1770: getmonth_mb: Assertion `mblength != (-1) && *wpp == ((void
> *)0)' failed.

That message isn't generated by GNU sort.

Most likely it's a bug in Red Hat's patches to GNU sort,
so I'd file a bug report with Red Hat.

I would mention the output of the shell commands "sort --version" and
"locale" when you file that bug report.


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

[patch] Adding Numerical Suffixes to Split

[Capt Jesse Kornblum USAF]

Sorry it's been so long since I've written; the Air Force moved me in 
the past month.

I'm still interested in adding support for numerical suffixes to split.

Several people have commented that the change from alphabetic suffixes 
to numerical ones can be accomplished via a shell script. That's true, 
but my question to you, is: Why? Why should the user have to remember a 
long line of arcane shell commands instead of just adding a single 
command line flag that already exists in a sister program (csplit)?

The numerical suffix is *the* standard for forensic images (think dd 
files, not graphics). Originally developed for a forensic imaging 
program called Safeback in late 80's, every forensic examination program 
now uses numerical suffixes to identity parts of a single image. Such 
programs include EnCase (http://encase.com/), iLook 
(http://www.ilook-forensics.org/), and Autopsy (http://www.sleuthkit.org/).

Your concern for preserving the split standard is admirable, but I don't 
think that this patch will break that standard. That is, files created 
with numerical suffixes can be read in the same manner as files created 
with alphabetic suffixes. Here's an example with a small text file 
called "bar." I split the 'bar' file using regular split and then my 
modified version. Both can then be 'cat'ed back together to be the same 
file.

$ ls -l bar
-rw-r--r--1 jessek   users5120 Aug  7 15:34 bar
$ split -b 500 bar normal
$ /home/jessek/coreutils-5.0/src/split -n -b 500 bar digits
$ ls normal* digits*
digits01  digits04  digits07  digits10  normalab  normalae  normalah 
normalak
digits02  digits05  digits08  digits11  normalac  normalaf  normalai
digits03  digits06  digits09  normalaa  normalad  normalag  normalaj
$ cat normal* > all-normal
$ cat digits* > all-digits
$ diff all-normal all-digits
$

Thus, any set of files created with numerical suffixes is still 
compatible with any set of files created with alphabetic suffixes. I'm 
open to argument on this point, of course. :)

Somebody asked if csplit would work for our purposes. Unfortunately we 
need a program that splits files based on their size. csplit looks only 
at a file's content.

Below, as requested, is the formatted patch for split to allow numerical 
suffixes. (I had some CVS issues, but think I got it right.)

2003-08-08  Jesse Kornblum  <[EMAIL PROTECTED]>

   Add support for numerical suffixes in split

   * src/split.c - Add support for -n

Index: patch.c
===
RCS file: /cvsroot/coreutils/coreutils/patch,v
retrieving revision x.x
diff -p -u -rx.x patch.c
--- split-orig.cThu Aug  7 15:00:25 2003
+++ split.c Thu Aug  7 15:11:11 2003
@@ -63,6 +63,9 @@ static size_t suffix_length = DEFAULT_SU
/* Name of input file.  May be "-".  */
static char *infile;
+/* If non-zero, use numeric suffixes instead of characters */
+static int suffix_type;
+
/* Descriptor on which input file is open.  */
static int input_desc;
@@ -78,6 +81,7 @@ static struct option const longopts[] =
  {"bytes", required_argument, NULL, 'b'},
  {"lines", required_argument, NULL, 'l'},
  {"line-bytes", required_argument, NULL, 'C'},
+  {"numbers", no_argument, &suffix_type, 'n'},
  {"suffix-length", required_argument, NULL, 'a'},
  {"verbose", no_argument, &verbose, 0},
  {GETOPT_HELP_OPTION_DECL},
@@ -109,6 +113,7 @@ Mandatory arguments to long options are
  -a, --suffix-length=N   use suffixes of length N (default %d)\n\
  -b, --bytes=SIZEput SIZE bytes per output file\n\
  -C, --line-bytes=SIZE   put at most SIZE bytes of lines per output 
file\n\
+  -n, --numbers   use digits for suffixes instead of numbers\n\
  -l, --lines=NUMBER  put NUMBER lines per output file\n\
"), DEFAULT_SUFFIX_LENGTH);
  fputs (_("\
@@ -143,7 +148,12 @@ next_file_name (void)
  outfile = xmalloc (outfile_length + 1);
  outfile_mid = outfile + outbase_length;
  memcpy (outfile, outbase, outbase_length);
-  memset (outfile_mid, 'a', suffix_length);
+  if (!suffix_type)
+   memset (outfile_mid, 'a', suffix_length);
+  else {
+   memset (outfile_mid, '0', suffix_length);
+   outfile_mid[suffix_length - 1] = '1';
+  }
  outfile[outfile_length] = 0;

#if ! _POSIX_NO_TRUNC && HAVE_PATHCONF && defined _PC_NAME_MAX
@@ -165,10 +175,17 @@ next_file_name (void)
  /* Increment the suffix in place, if possible.  */
  char *p;
-  for (p = outfile_mid + suffix_length; outfile_mid < p; *--p = 'a')
-   if (p[-1]++ != 'z')
- return;
-  error (EXIT_FAILURE, 0, _("Output file suffixes exhausted"));
+  if (!suffix_type) {
+   for (p = outfile_mid + suffix_length; outfile_mid < p; *--p = 'a')
+ if (p[-1]++ != 'z')
+   return;
+   error (EXIT_FAILURE, 0, _("Output file suffixes exhausted"));
+  } else {
+   for (p = outfile_mid + suffix_length; outfile_mid < p; *--p = '0')
+ if (p[-1]++ 

Re: fold -s leaves shameful wasted blanks at end of lines

[Jim Meyering]

Dan Jacobson <[EMAIL PROTECTED]> wrote:
> fold -s leaves shameful wasted blanks at end of lines:
...
> Therefore there needs to be another switch to do away with them.

Yes.  It looks like POSIX requires that.

  # printf 'a b\n'|fold -w2 -s|cat -A
  a $
  b$

How about piping the result through a filter like this?

  perl -pe 's/[ \t]+$//'


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: glibc utimes glitch with coreutils 'touch'

[Jim Meyering]

Paul Eggert <[EMAIL PROTECTED]> wrote:
> I'll submit an alternate patch to coreutils so that it works around
> this glibc glitch.  The simplest workaround is to not invoke utimes
> when building with glibc; perhaps I can improve on that, but I don't
> know.

We don't have to condemn the coreutils always
to use the inferior utime interface on glibc systems.
Instead, I'm adding a configure-time test of utimes, so that
if it works, coreutils will use it.

Here's the C program it'll compile and run.
So far it compiles and exits successfully on all systems listed
except for the one with Debian libc6 version 2.3.2-1.

/* tested with gcc on the following:
   AIX 4.3  (both gcc and cc)
   openbsd 3.2
   solaris 9
   netbsd 1.6
   OSF1 V4.0 (both gcc and cc)
   linux 2.4.20, 2.4.21
*/
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int
main ()
{
  static struct timeval timeval[2] = {{9, 10}, {11, 12}};
  struct stat sbuf;
  char const *file = "x";
  FILE *f;

  exit ( ! ((f = fopen (file, "w"))
&& fclose (f) == 0
&& utimes (file, timeval) == 0
&& lstat (file, &sbuf) == 0
&& sbuf.st_atime == timeval[0].tv_sec
&& sbuf.st_mtime == timeval[1].tv_sec) );
}


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

regex.m4 encoding problem; '# serial'

[Paul Eggert]

Jim Meyering <[EMAIL PROTECTED]> writes:

> > * m4/regex.m4: Sync with gnulib; this is just a change from \371
> > to \201 to fix an encoding glitch I introduced.
> 
> I don't understand this part.
> The byte that was there before sure looks like it was \371:

Oops.  Thanks for pointing that out.  It looks like my copy of
regex.m4 got confused after Emacs had its way with that character;
probably something to do with UTF-8.  Sorry about that.  I installed
the following patch into gnulib.  Now gnulib matches coreutils, except
for the serial number.

While we're on the subject of serial number, would anyone mind if I
got rid of header comments like 'serial 19'?  I seem to recall there
was some sentiment for getting rid of the serial numbers now that
everything's CVSed, but don't recall the resolution of that.

2003-08-09  Paul Eggert  <[EMAIL PROTECTED]>

* regex.m4 (jm_INCLUDED_REGEX): Change "\201" to "\371";
apparently Emacs's Unicode mode got confused before my 2003-08-05
checkin.

Index: regex.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/regex.m4,v
retrieving revision 1.34
retrieving revision 1.35
diff -p -u -r1.34 -r1.35
--- regex.m47 Aug 2003 19:33:14 -   1.34
+++ regex.m49 Aug 2003 20:04:34 -   1.35
@@ -1,4 +1,4 @@
-#serial 18
+#serial 19
 
 dnl Initially derived from code in GNU grep.
 dnl Mostly written by Jim Meyering.
@@ -52,7 +52,7 @@ AC_DEFUN([jm_INCLUDED_REGEX],
/* The following example is derived from a problem report
against gawk from Jorge Stolfi <[EMAIL PROTECTED]>.  */
memset (®ex, 0, sizeof (regex));
-   s = re_compile_pattern ("[[an\201]]*n", 7, ®ex);
+   s = re_compile_pattern ("[[an\371]]*n", 7, ®ex);
if (s)
  exit (1);
 


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: Problem with tail

[Bob Proulx]

Paul Eggert wrote:
> [EMAIL PROTECTED] writes:
> > $ tail --version
> > tail (textutils) 2.0.21
> 
> That's a fairly old version.  I have no problem with the coreutils 5.0
> tail on Debian:

I have definitely used 2.0.21 on large files previously.  While old I
don't think that is the root cause of the problem.  I suspect that if
it were analyzed completely it would be found that that particular
compilation was compiled without large files support.  The newer
autoconf is much better at detecting this than the older version used
at that time.  In the old days you had to tell configure how to enable
large file support.  This is really not an issue for tail so much as
it is for the operating system and the compiler.

If that version was compiled from source then recompiling it with
large file support should enable this functionality if your operating
system also supports large files.  But since it is so old I agree with
Paul that your best action is to update to the current coreutils.

Bob


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: possible new feature for chmod

[Paul Eggert]

"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:

>Why not fix these problems by disambiguating the syntax?  You can put
>a new character in front of the new-format mode strings.  E.g.,
> 
>  chmod %-rw-rw-r-- file
> 
> Why not fix it with a seperate option instead (which this basicly is)?

Because the same syntax is used in other places, e.g.:

  install -m %-rw-rw-r-- file directory
  mkdir -m %drwxr-xr-x directory

and similarly for mkfifo and mknod.

I suppose we could use a --ls-mode option instead.  But it seems more
consistent to me to make the suggestion improvement part of the mode
syntax, since it's meant to take the place of 755, which is already
part of the mode syntax.

If you don't like '%', perhaps you'd prefer '@'?  That might be a
little clearer.


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: Misc Problems with coreutils-5.0.90

[Jim Meyering]

Vin Shelton <[EMAIL PROTECTED]> wrote:
> 3. 'shred' fails the remove test under both SunOS-5.5.1 and SunOS-5.8:

Thanks for reporting that.
It was fixed like this:

2003-08-01  Jim Meyering  <[EMAIL PROTECTED]>

* tests/shred/remove: Ensure that $? is 0 for the final `exit 0'.
Otherwise, with at least the /bin/sh from HPUX 10.20,
the trap code would end up converting that to exit 1 and thus an
unexpected test failure.  Reported by Christian Krackowizer.

Index: tests/shred/remove
===
RCS file: /fetish/cu/tests/shred/remove,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -p -u -r1.9 -r1.10
--- tests/shred/remove  19 Jul 2003 11:47:17 -  1.9
+++ tests/shred/remove  1 Aug 2003 22:33:04 -   1.10
@@ -34,6 +34,6 @@ fail=0
 # This would take so long that it appears to infloop
 # when using version from fileutils-4.0k.
 # When the command completes, expect it to fail.
-shred -u $file > /dev/null 2>&1 && fail=1
+shred -u $file > /dev/null 2>&1 && fail=1 || :
 
 exit $fail


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

patch to add microsecond resolution support to cp -p, etc.

[Paul Eggert]

Sun patch 109933-02 for Solaris 8 sparc, released August 1, added
support to "cp -p" to set file timestamps to microsecond resolution,
instead of the old behavior, which set them only to 1-second
resolution.  Sun "make" relies on this new behavior so that "make"
actions like "dest: source; cp -p source dest" do not confuse "make".

Here is a patch to add this capability to GNU coreutils.

2003-08-06  Paul Eggert  <[EMAIL PROTECTED]>

* NEWS: Add support for setting file timestamps to microsecond
resolution, on hosts that support this.
* lib/Makefile.am (libeftish_a_SOURCES): Add utimens.c, utimens.h.
* lib/utimens.c, lib/utimens.h: New files.
* m4/prereq.m4 (jm_PREREQ): Require gl_UTIMENS.
* m4/timespec.m4: Sync with gnulib.
* m4/utimens.m4: New file.
* src/copy.c, src/cp.c, src/install.c, src/touch.c: Include timespec.h.
* src/copy.c (copy_internal):
Set file timestamps with utimens, not utimes.
* src/cp.c (re_protect): Likewise.
* src/install.c (change_timestamps): Likewise.
* src/touch.c (newtime, touch, main): Likewise.

diff -Naurp coreutils/NEWS coreutils-cp-p/NEWS
--- coreutils/NEWS  2003-08-01 15:35:57.0 -0700
+++ coreutils-cp-p/NEWS 2003-08-06 18:12:31.948642000 -0700
@@ -29,6 +29,12 @@ GNU coreutils NEWS  
   but POSIX did not actually require this undesirable behavior, so it
   has been removed.
 
+  cp, install, mv, and touch now preserve microsecond resolution on
+  file timestamps, on platforms that have the 'utimes' system call.
+  Unfortunately there is no system call yet to preserve file
+  timestamps to their full nanosecond resolution; microsecond
+  resolution is the best we can do right now.
+
 ** Bug fixes
 
   kill no longer tries to operate on argv[0] (introduced in 5.0.1)
diff -Naurp coreutils/lib/Makefile.am coreutils-cp-p/lib/Makefile.am
--- coreutils/lib/Makefile.am   2003-07-31 23:38:38.0 -0700
+++ coreutils-cp-p/lib/Makefile.am  2003-08-06 16:07:00.445934000 -0700
@@ -112,6 +112,7 @@ libfetish_a_SOURCES = \
   unistd-safer.h \
   unlocked-io.h \
   userspec.c \
+  utimens.c utimens.h \
   version-etc.c version-etc.h \
   xalloc.h \
   xgetcwd.c xgetcwd.h \
diff -Naurp coreutils/lib/utimens.c coreutils-cp-p/lib/utimens.c
--- coreutils/lib/utimens.c 1969-12-31 16:00:00.0 -0800
+++ coreutils-cp-p/lib/utimens.c2003-08-06 17:22:16.829405000 -0700
@@ -0,0 +1,63 @@
+/* Copyright (C) 2003 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published by the
+   Free Software Foundation; either version 2, or (at your option) any
+   later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software Foundation,
+   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
+
+/* Written by Paul Eggert.  */
+
+/* derived from a function in touch.c */
+
+#ifdef HAVE_CONFIG_H
+# include 
+#endif
+
+#include "utimens.h"
+
+#if HAVE_UTIME_H
+# include 
+#endif
+
+/* Some systems (even some that do have ) don't declare this
+   structure anywhere.  */
+#ifndef HAVE_STRUCT_UTIMBUF
+struct utimbuf
+{
+  long actime;
+  long modtime;
+};
+#endif
+
+/* Set the access and modification time stamps of FILE to be
+   TIMESPEC[0] and TIMESPEC[1], respectively.  */
+
+int
+utimens (char const *file, struct timespec const timespec[2])
+{
+  /* There's currently no interface to set file timestamps with
+ nanosecond resolution, so do the best we can, discarding any
+ fractional part of the timestamp.  */
+#if HAVE_UTIMES
+  struct timeval timeval[2];
+  timeval[0].tv_sec = timespec[0].tv_sec;
+  timeval[0].tv_usec = timespec[0].tv_nsec / 1000;
+  timeval[1].tv_sec = timespec[1].tv_sec;
+  timeval[1].tv_usec = timespec[1].tv_nsec / 1000;
+  return utimes (file, timeval);
+#else
+  struct utimbuf utimbuf;
+  utimbuf.actime = timespec[0].tv_sec;
+  utimbuf.modtime = timespec[1].tv_sec;
+  return utime (file, &utimbuf);
+#endif
+}
diff -Naurp coreutils/lib/utimens.h coreutils-cp-p/lib/utimens.h
--- coreutils/lib/utimens.h 1969-12-31 16:00:00.0 -0800
+++ coreutils-cp-p/lib/utimens.h2003-08-06 15:05:40.049938000 -0700
@@ -0,0 +1,2 @@
+#include "timespec.h"
+int utimens (char const *, struct timespec const [2]);
diff -Naurp coreutils/m4/prereq.m4 coreutils-cp-p/m4/prereq.m4
--- coreutils/m4/prereq.m4  2003-06-06 00:07:13.0 -0700
+++ coreutils-cp-p/m4/prereq.m4 2003-08-06 16:34:47.728722000 -0700
@@ -31,6 +31,7 @@ AC_DEFUN([jm_PREREQ],
   AC_REQUIRE([jm_PREREQ_

Re: date(1) treats TZ '' differently from unset

[Ed Avis]

On 10 Aug 2003, Paul Eggert wrote:

>>% (unset TZ; date +%z)
>>+0100
>>% (TZ= date +%z)
>>+

>This is a C library issue, not a coreutils issue, since coreutils
>simply repeats what the C library tells it.

What does POSIX say about date(1) and the TZ variable?

-- 
Ed Avis <[EMAIL PROTECTED]>




___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: Problem with tail

[Paul Eggert]

[EMAIL PROTECTED] writes:

> $ tail --version
> tail (textutils) 2.0.21

That's a fairly old version.  I have no problem with the coreutils 5.0
tail on Debian:

   22-mae $ tail -n 1 big
   bar
   23-mae $ ls -l big
   -rw-rw-r--1 eggert   eggert   4294967363 2003-08-11 18:50 big
   24-mae $ uname -a
   Linux mae 2.4.21-pre3-40828c #1 Tue Jan 7 17:50:25 PST 2003 i686 GNU/Linux
   25-mae $ tail --version | sed 1q
   tail (coreutils) 5.0

Perhaps all you need to do is update coreutils.  Also, it's possible
that it's a problem with a cygwin library somewhere.


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

no example of date -d 'the next occurrence of 17:30'

[Dan Jacobson]

The Info node "Relative items in date strings" and/or
"Examples of `date'" lack an example of how one can specify the next
occurrence of say 17:30.  I.e. if now the time is 15:00, our -d string
will print
$ date -d 'x'
Fri Aug 15 17:30:00 GMT-8 2003
but if now is 18:00, then the very same -d string will print
$ date -d 'x'
Sat Aug 16 17:30:00 GMT-8 2003

Tell the user what to use where I put x, or tell the user it is
impossible and he needs to what ; shell script instead. 

No, it's not
$ date -d 'next 17:30'
date: invalid date `next 17:30'

If the best way to do it is

t=17:30
echo -n "The next occurrence of $t is "
if test `date +%s -d $t` -gt `date +%s`
then date
else date -d "$t tomorrow"
fi

then say so.



P.S. after the Date info pages, one hits
Toolbox Introduction


   This month's column is only peripherally related to the GNU Project,

Hey, I'm reading Info.  Not a 'This month's column' ... please edit.


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: [Bug-gnulib] vasnprintf.m4 patch for Solaris 2.5.1 wcslenproblem

[Jim Meyering]

> 2003-08-08  Paul Eggert  <[EMAIL PROTECTED]>
>
>   * m4/vasnprintf.m4 (gl_PREREQ_VASNPRINTF):
>   Solaris 2.5.1 needs -lw to get the wcslen function.

I've applied that.  Thanks.


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

coreutils-5.0.90 patch 1: build feedback

[Nelson H. F. Beebe]

I applied the patches to tests/shred/remove, src/nice.c, and
lib/stdbool_.h in coreutils-5.0.90 and repackaged it as
coreutils-5.0.90.1, then launched builds on just those platforms where
build failures had previously occurred.

I still get some failures:


Machinetype:Apple PowerMac G4 (2 1.4 GHz PowerPC 7450 CPUs, 2GB RAM);   
Darwin 6.5 (MacOS 10.2.5)
Remote gcc version: gcc (GCC) 3.3
Remote g++ version: g++ (GCC) 3.3
Configure environment:  CC=gcc CXX=g++ LDFLAGS="-R/usr/local/lib" 

gcc  -g -O2  -R/usr/local/lib -o hostid  hostid.o ../lib/libfetish.a 
/usr/local/lib/libintl.dylib /usr/local/lib/libiconv.dylib ../lib/libfetish.a 
if gcc -DHAVE_CONFIG_H -I. -I. -I..  -I.. -I. -I../lib -I../lib -I/usr/local/include  
-g -O2 -MT nice.o -MD -MP -MF ".deps/nice.Tpo" \
  -c -o nice.o `test -f 'nice.c' || echo './'`nice.c; \
then mv -f ".deps/nice.Tpo" ".deps/nice.Po"; \
else rm -f ".deps/nice.Tpo"; exit 1; \
fi
gcc: unrecognized option `-R/usr/local/lib'
/usr/bin/ld: warning table of contents of library: ../lib/libfetish.a not sorted 
slower link editing will result (use the ranlib(1) -s option)
/usr/bin/ld: warning dynamic shared library: /usr/local/lib/libiconv.dylib not made a 
weak library in output with MACOSX_DEPLOYMENT_TARGET environment variable set to: 10.1
In file included from nice.c:29:
/usr/include/sys/resource.h:81: error: field `ru_utime' has incomplete type
/usr/include/sys/resource.h:82: error: field `ru_stime' has incomplete type


Machinetype:Intel Pentium III (600 MHz);FreeBSD 5.0
Remote gcc version: gcc (GCC) 3.3
Remote g++ version: g++ (GCC) 3.3
Configure environment:  CC=gcc CXX=g++ LDFLAGS=-Wl,-rpath,/usr/local/lib 

if gcc -DHAVE_CONFIG_H -I. -I. -I..  -I.. -I. -I../lib -I../lib -I/usr/local/include  
-g -O2 -MT nice.o -MD -MP -MF ".deps/nice.Tpo" \
  -c -o nice.o `test -f 'nice.c' || echo './'`nice.c; \
then mv -f ".deps/nice.Tpo" ".deps/nice.Po"; \
else rm -f ".deps/nice.Tpo"; exit 1; \
fi
In file included from nice.c:29:
/usr/include/sys/resource.h:61: error: field `ru_utime' has incomplete type
/usr/include/sys/resource.h:62: error: field `ru_stime' has incomplete type
make[3]: make[3]: Leaving directory `/local/build/coreutils-5.0.90.1/src'


Machinetype:Intel Pentium III (600 MHz);OpenBSD 3.2 GENERIC#25 i386
Remote gcc version: gcc (GCC) 3.3
Remote g++ version: g++ (GCC) 3.3
Configure environment:  CC=gcc CXX=g++ LDFLAGS=-Wl,-rpath,/usr/local/lib 

if gcc -DHAVE_CONFIG_H -I. -I. -I..  -I.. -I. -I../lib -I../lib   -g -O2 -MT nice.o 
-MD -MP -MF ".deps/nice.Tpo" \
  -c -o nice.o `test -f 'nice.c' || echo './'`nice.c; \
then mv -f ".deps/nice.Tpo" ".deps/nice.Po"; \
else rm -f ".deps/nice.Tpo"; exit 1; \
fi
In file included from nice.c:29:
/usr/include/sys/resource.h:60: error: field `ru_utime' has incomplete type
/usr/include/sys/resource.h:61: error: field `ru_stime' has incomplete type
make[3]: make[3]: Leaving directory `/local/build/coreutils-5.0.90.1/src'


Machinetype:Sun Sun Blade 2000 (1015MHz);  Solaris 2.9
Remote c89 version: cc: Sun C 5.5 Patch 112760-01 2003/05/18
Remote CC version:  CC: Sun C++ 5.5 Patch 113817-01 2003/05/18
Configure environment:  CC=c89 CFLAGS="-xO5 -dalign -xlibmil -xcg92 -xsafe=mem" CXX=CC 
CXXFLAGS=-xO5 LDFLAGS=-R/usr/local/lib 

c89 -DHAVE_CONFIG_H -I. -I. -I..  -I.. -I. -I../lib -I../lib -I/usr/local/include  
-xO5 -dalign -xlibmil -xcg92 -xsafe=mem -c `test -f 'date.c' || echo './'`date.c
"make[3]: Leaving directory `/local/build/coreutils-5.0.90.1/src'
../lib/timespec.h", line 39: (struct) tag redeclared: timespec
c89: acomp failed for date.c
make[3]: *** [date.o] Error 2


Machinetype:Intel Pentium III (600 MHz);Solaris 2.9
Remote c89 version: cc: Sun WorkShop 6 update 2 C 5.3 Patch 111680-08 2003/02/10
Remote CC version:  CC: Sun WorkShop 6 update 2 C++ 5.3 Patch 111686-14 2003/03/24
Configure environment:  CC=c89 CXX=CC LDFLAGS=-R/usr/local/lib 

c89 -DHAVE_CONFIG_H -I. -I. -I..  -I.. -I. -I../lib -I../lib   -g -c `test -f 'date.c' 
|| echo './'`date.c
"../lib/timespec.h", line 39: (struct) tag redeclared: timespec
c89: acomp failed for date.c
make[3]: Leaving directory `/local/build/c89/coreutils-5.0.90.1/src'
make[2]: Leaving directory `/local/build/c89/coreutils-5.0.90.1/src'
make[3]: *** [date.o] Error 2


Machinetype:Sun Ultra Enterprise 5500 (4 CPUs); Solaris 2.8
Remote c89 version: cc: Sun WorkShop 6 update 2 C 5.3 Patch 111679-12 2003/05/18
Remote CC version:  CC: Sun WorkS

Re: coreutils-5.0.90 problems on Crays

[Paul Eggert]

Wendy Palm <[EMAIL PROTECTED]> writes:

> ! #if UINT_MAX == _UINT_MAX_64
> !   typedef unsigned int md5_uint32;
> ! #else
> !   /* The following line is intended to evoke an error.
> !  Using #error is not portable enough.  */
> !   "Cannot determine unsigned 32-bit data type."
> ! #endif

Sorry, I don't quite follow the need for this change.  Does that host
have a working ?  If so,  should define UINT_MAX,
USHRT_MAX, and ULONG_MAX.

Is the problem that there is no 32-bit integer type on that platform?
I worry that the code won't work in that case: it really assumes the
presence of a 32-bit int.

I have the same questions about the similar change to src/shred.c.


> ! bin_PROGRAMS = \[ chgrp chown chmod cp dd dircolors du \

Ouch.  I suspect that this will break 'make' programs on other hosts,
as there's no backslash-escape mechanism like that in standard 'make'.

What exactly is the problem if you use it without the backslash?
Perhaps there's another way to work around the problem.


> + #ifdef _UNICOS
> + int endusershell ();
> + int setusershell ();
> + #else
>   void endusershell ();
>   void setusershell ();
> + #endif /* _UNICOS */

I notice that su.c already does this:

/* Hide any system prototype for getusershell.
   This is necessary because some Cray systems have a conflicting
   prototype (returning `int') in .  */
#define getusershell _getusershell_sys_proto_

Does a similar trick work for endusershell and setusershell?
That would be more consistent.


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: -x doesn't work in cp

[Jim Meyering]

Pär Lidén <[EMAIL PROTECTED]> wrote:
> It seems -x doesn't work in cp. When I tried to copy my whole "/"
> filesystem to a new, freshly formatted filesystem, cp did copy files in
> /devfs, /home and /proc, despite these being different filesystems. This
> is very bad, cause the whole process hung when cp tried to copy some files
> in /proc.
> The command line I used (while standing in "/") was
> cp -ax * /mnt
> with the new filesystem mounted on /mnt
>
> I'm using the testing distribution of Debian, with kernel 2.6.0-test3.
> The coreutils version reported by "cp --version" is 5.0, and Debian
> package management says 5.0-5.

Thanks for the report.
However, cp's -x option works fine if you use it the right way :-)
Try this next time:

  cp -ax / /mnt


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

-x doesn't work in cp

[Pär Lidén]

Hello.
It seems -x doesn't work in cp. When I tried to copy my whole "/" 
filesystem to a new, freshly formatted filesystem, cp did copy files in
/devfs, /home and /proc, despite these being different filesystems. This
is very bad, cause the whole process hung when cp tried to copy some files
in /proc.
The command line I used (while standing in "/") was
cp -ax * /mnt
with the new filesystem mounted on /mnt

I'm using the testing distribution of Debian, with kernel 2.6.0-test3.
The coreutils version reported by "cp --version" is 5.0, and Debian
package management says 5.0-5.

Regards
   Pär Lidén



___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: bug in tr, version 4.5.3

[Bob Proulx]

Alwin Leerling wrote:
> I think I might have stumbled on a bug in tr:

Thank you very much for the report.  But I don't think this is a bug.
I think you are using tr incorrectly.

> Command in bash shell:
>   echo fdhrnzvfu bffvsentr | tr [a-z] [n-z][a-m]
> 
> Expected output:
>   squeamish ossifrage
> 
> Output from command
>   squc]kgsf ossigdr]ec

Try this instead:

  echo fdhrnzvfu bffvsentr | tr '[a-z]' '[n-za-m]'

Also remember that brackets are expanded by the shell to match file
names.  Be sure to quote them to prevent that.

Bob


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: date(1) treats TZ '' differently from unset

[Paul Eggert]

Ed Avis <[EMAIL PROTECTED]> writes:

> What does POSIX say about date(1) and the TZ variable?

POSIX says that if TZ is unset, "implementation-defined default
timezone information shall be used"; see
.
POSIX does not specify the behavior if TZ is set but empty; see
.
So GNU "date" conforms.


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: wait4 - proposed new program

[Paul Eggert]

Martin von Gagern <[EMAIL PROTECTED]> writes:

> I thought perhaps it should be part of coreutils. What do you think?

wait4 sounds like a nice program to have, but wouldn't it be more at
home in FAM itself?  Or perhaps fileschanged (see below)?

> BTW: Do you know anything like this around?

fileschanged  is not exactly the
same, but it seems to me that you could write wait4 as a script that
invokes fileschanged, at least as a first approximation.


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: glibc utimes glitch with coreutils 'touch'

[Paul Eggert]

Jim Meyering <[EMAIL PROTECTED]> writes:

> What problem arises in coreutils if we don't detect/work-around
> that difference?

For example, 'touch -r A B', 'cp -p A B', etc. could set B's timestamp
to be in the future; this could give 'make' conniptions.

> I think that the bug in glibc won't end up lasting long
> enough to make it onto a significant number of systems.
> And for those users who are progressive (or maybe reckless :-) enough
> that they get a losing glibc, I think it's reasonable to expect
> them to upgrade pretty quickly to a version with the fix.

OK, let's assume this for now.  (Yay!  It's less work.)


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: coreutils-5.0.90 problems on Crays

[Wendy Palm]

Paul Eggert wrote:

Wendy Palm <[EMAIL PROTECTED]> writes:


! #if UINT_MAX == _UINT_MAX_64
!   typedef unsigned int md5_uint32;
! #else
!   /* The following line is intended to evoke an error.
!  Using #error is not portable enough.  */
!   "Cannot determine unsigned 32-bit data type."
! #endif
Sorry, I don't quite follow the need for this change.  Does that host
have a working ?  If so,  should define UINT_MAX,
USHRT_MAX, and ULONG_MAX.


i do have a limits.h and it does define UINT_MAX, USHRT_MAX
and ULONG_MAX.  but, on a cray, there is no UINT_MAX_32_BITS,
and all these values are set to _UNIT_MAX_64 so the whole ifdef falls through.
Is the problem that there is no 32-bit integer type on that platform?
I worry that the code won't work in that case: it really assumes the
presence of a 32-bit int.
I have the same questions about the similar change to src/shred.c.


traditional cray machines (currently, t3e, sv1, ts, j90) do not have a 32bit int.
they have 64 bit ints (all datatypes are 64bits except char and on
the t3e where a short is 32bits).

the newer cray architectures (X1 and on) do have 32bit ints (and the traditional 

long, short, etc. types).

with the change i proposed, the only error i have with the tests is date-tests and 

i haven't had time to check what that problem is yet.

i've run sh-utils with a similar mod for almost 2 years and haven't had any problems.

i'd be interested to know what programs are potentially problems with >32bits.
possibly some shifting assumptions may be messed up.

! bin_PROGRAMS = \[ chgrp chown chmod cp dd dircolors du \
Ouch.  I suspect that this will break 'make' programs on other hosts,
as there's no backslash-escape mechanism like that in standard 'make'.
What exactly is the problem if you use it without the backslash?
Perhaps there's another way to work around the problem.


i get this error
cc  -hnointrinsics  -Wl,-Dmsglevel=334:fatal -o [  lbracket.o 
../lib/libfetish.a  ../lib/libfetish.a -lgen
GETTMC: invalid primary machine name on TARGET statement
Make: "cc  -hnointrinsics  -Wl,-Dmsglevel=334:fatal -o [  lbracket.o ../lib/libfetish.a  
../lib/libfetish.a -lgen ": Error code 1
Make: "make  all-am": Error code 1
doublequotes and singlequotes also work.  would they work on other hosts?


+ #ifdef _UNICOS
+ int endusershell ();
+ int setusershell ();
+ #else
 void endusershell ();
 void setusershell ();
+ #endif /* _UNICOS */
I notice that su.c already does this:

/* Hide any system prototype for getusershell.
   This is necessary because some Cray systems have a conflicting
   prototype (returning `int') in .  */
#define getusershell _getusershell_sys_proto_
Does a similar trick work for endusershell and setusershell?
That would be more consistent.


i didn't notice that one.  yes, that would work.



--
wendy palm
Cray Open Software Development, Cray Inc.
wendyp at cray.com, 651-605-9154


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: cp incompatible with older versions!

[Jim Meyering]

Steven Scholz <[EMAIL PROTECTED]> wrote:
> the cp from recent coreutils is not compatible with cp from "GNU fileutils 4.0.36"
> package(as found on RH 7.1).
>
> The old "cp -pr README.txt README_lang foo/bar/README.txt /tmp" would
> copy three files but would overwrite the first README.txt with the
> content of foo/bar/README.txt without further notice.
>
> But newer versions will complain or fail:
>
> RH-8.0:   cp (fileutils) 4.1.9
>
> -> cp -pr README.txt README_lang foo/bar/README.txt /tmp
> cp: warning: overwriting just-created `/tmp/README.txt' with `foo/bar/README.txt'
>
> RH-9: cp (coreutils) 4.5.3
>
> -> cp -pr README.txt README_lang foo/bar/README.txt /tmp
> cp: warning: overwriting just-created `/tmp/README.txt' with `foo/bar/README.txt'
>
> SuSE 8.2: cp (coreutils) 4.5.8
>
> -> cp -pr README.txt README_lang foo/bar/README.txt /tmp
> cp: will not overwrite just-created `/tmp/README.txt' with `foo/bar/README.txt'
>
> Is that a bug or a feature!?

It's a feature.

Would you prefer to have cp silently succeed?
That would be bad.
Then the user might think it's ok to remove the
files that s/he thinks have been successfully copied.


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

cp incompatible with older versions!

[Steven Scholz]

Hi there,

the cp from recent coreutils is not compatible with cp from "GNU fileutils 4.0.36"
package(as found on RH 7.1).
The old "cp -pr README.txt README_lang foo/bar/README.txt /tmp" would
copy three files but would overwrite the first README.txt with the
content of foo/bar/README.txt without further notice.
But newer versions will complain or fail:

RH-8.0:		cp (fileutils) 4.1.9

-> cp -pr README.txt README_lang foo/bar/README.txt /tmp
cp: warning: overwriting just-created `/tmp/README.txt' with `foo/bar/README.txt'
RH-9:		cp (coreutils) 4.5.3

-> cp -pr README.txt README_lang foo/bar/README.txt /tmp
cp: warning: overwriting just-created `/tmp/README.txt' with `foo/bar/README.txt'
SuSE 8.2:	cp (coreutils) 4.5.8

-> cp -pr README.txt README_lang foo/bar/README.txt /tmp
cp: will not overwrite just-created `/tmp/README.txt' with `foo/bar/README.txt'
Is that a bug or a feature!?

Thanks,

Steven



___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: make check fix

[Paul Eggert]

Simon Josefsson <[EMAIL PROTECTED]> writes:

> For some reason sort in LANG=sv_SE.UTF-8 sort 'w' equal to 'v', making
> 'wc' end up before 'vdir', and a check fails.

Thanks for pointing this out.  But the patch isn't quite right, since
you can't portably set LC_COLLATE to C without also setting LC_CTYPE
consistently, as the resulting behavior is undefined.  It's simpler
just to set LC_ALL.  Also, there are some other places that have the
same problem.  How about the following patch instead?

2003-08-14  Paul Eggert  <[EMAIL PROTECTED]>

* Makefile.maint (LC_ALL): Set to C.
* man/Makefile.am (ASSORT): New var.
(check-x-vs-1, programs): Use it.
* src/Makefile.am (ASSORT, check-README, ../AUTHORS): Likewise.
* tests/Makefile.am (ASSORT, all_programs): Likewise.

Index: Makefile.maint
===
RCS file: /cvsroot/coreutils/coreutils/Makefile.maint,v
retrieving revision 1.153
diff -p -u -r1.153 Makefile.maint
--- Makefile.maint  13 Aug 2003 07:33:17 -  1.153
+++ Makefile.maint  14 Aug 2003 18:23:04 -
@@ -43,6 +43,10 @@ my_distdir = $(PACKAGE)-$(VERSION)
 # Used for diffs and xdeltas.
 release_archive_dir ?= ../release
 
+# Prevent programs like 'sort' from considering distinct strings to be equal.
+# Doing it here saves us from having to set LC_ALL elsewhere in this file.
+export LC_ALL = C
+
 
 
 ## --- ##
Index: man/Makefile.am
===
RCS file: /cvsroot/coreutils/coreutils/man/Makefile.am,v
retrieving revision 1.21
diff -p -u -r1.21 Makefile.am
--- man/Makefile.am 26 Jul 2003 08:59:09 -  1.21
+++ man/Makefile.am 14 Aug 2003 18:23:05 -
@@ -135,21 +135,26 @@ mapped_name = `echo $*|sed 's/install/gi
 
 check-local: check-x-vs-1 check-programs-vs-x
 
+# Sort in traditional ASCII order, regardless of the current locale;
+# otherwise we may get into trouble with distinct strings that the
+# current locale considers to be equal.
+ASSORT = LC_ALL=C sort
+
 # Ensure that for each .x file in this directory, there is a
 # corresponding .1 file in the definition of $(dist_man_MANS) above.
 .PHONY: check-x-vs-1
 check-x-vs-1:
PATH=../src$(PATH_SEPARATOR)$$PATH; export PATH;\
t=ls-files.;\
-   (cd $(srcdir) && ls -1 *.x) | sed 's/\.x$$//' | sort > $$t; \
-   echo $(dist_man_MANS) | fmt -w1 | sed 's/\.1$$//' | sort -u \
+   (cd $(srcdir) && ls -1 *.x) | sed 's/\.x$$//' | $(ASSORT) > $$t;\
+   echo $(dist_man_MANS) | fmt -w1 | sed 's/\.1$$//' | $(ASSORT)   \
  | diff - $$t || { rm $$t; exit 1; };  \
rm $$t
 
 programs = \
   echo 'spy:;@echo $$(all_programs)'   \
 | MAKEFLAGS= $(MAKE) -s -C $(srcdir)/../src -f Makefile -f - spy   \
-| fmt -1 | sort -u | grep -v '\['
+| fmt -1 | $(ASSORT) -u | grep -v '\['
 
 .PHONY: check-programs-vs-x
 check-programs-vs-x:
Index: src/Makefile.am
===
RCS file: /cvsroot/coreutils/coreutils/src/Makefile.am,v
retrieving revision 1.31
diff -p -u -r1.31 Makefile.am
--- src/Makefile.am 26 Jul 2003 07:28:43 -  1.31
+++ src/Makefile.am 14 Aug 2003 18:23:05 -
@@ -211,6 +211,11 @@ all_programs = \
 $(bin_SCRIPTS) \
   $(EXTRA_PROGRAMS)
 
+# Sort in traditional ASCII order, regardless of the current locale;
+# otherwise we may get into trouble with distinct strings that the
+# current locale considers to be equal.
+ASSORT = LC_ALL=C sort
+
 pm = progs-makefile
 pr = progs-readme
 # Ensure that the list of programs in README matches the list
@@ -220,7 +225,7 @@ check: check-README check-misc
 check-README:
rm -rf $(pr) $(pm)
echo $(all_programs) \
- | tr -s ' ' '\n' | sort -u > $(pm)
+ | tr -s ' ' '\n' | $(ASSORT) -u > $(pm) && \
sed -n '/^The programs .* are:/,/^[a-zA-Z]/p' $(top_srcdir)/README \
  | sed -n '/^   */s///p' | tr -s ' ' '\n' > $(pr)
diff $(pm) $(pr) && rm -rf $(pr) $(pm)
@@ -259,6 +264,6 @@ s2 = '/^\#define AUTHORS /{;n;$(sed_
  prog=`echo $$i|sed 's/\.c$$//'`;  \
  echo "$$prog: $$a";   \
fi; \
- done | sort -u ) > [EMAIL PROTECTED]
+ done | $(ASSORT) -u ) > [EMAIL PROTECTED]
chmod a-w [EMAIL PROTECTED]
mv [EMAIL PROTECTED] $@
Index: tests/Makefile.am
===
RCS file: /cvsroot/coreutils/coreutils/tests/Makefile.am,v
retrieving revision 1.10
diff -p -u -r1.10 Makefile.am
--- tests/Makefile.am   1 Aug 2003 22:32:41 -   1.10
+++ tests/Makefile.am   14 Aug 2003 18:23:05 -
@@ -1,9 +1,14 

make check fix

[Simon Josefsson]

For some reason sort in LANG=sv_SE.UTF-8 sort 'w' equal to 'v', making
'wc' end up before 'vdir', and a check fails.

--- Makefile.am.~1.31.~ Thu Jan  1 01:00:01 1970
+++ Makefile.am Thu Aug 14 13:12:29 2003
@@ -220,7 +220,7 @@
 check-README:
rm -rf $(pr) $(pm)
echo $(all_programs) \
- | tr -s ' ' '\n' | sort -u > $(pm)
+ | tr -s ' ' '\n' | LC_COLLATE=C sort -u > $(pm)
sed -n '/^The programs .* are:/,/^[a-zA-Z]/p' $(top_srcdir)/README \
  | sed -n '/^   */s///p' | tr -s ' ' '\n' > $(pr)
diff $(pm) $(pr) && rm -rf $(pr) $(pm)



___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: source code for 'df'

[Bob Proulx]

Please don't crosspost to so many different lists.

Kalyan Kumar wrote:
> I was wondering where I can find source code for 'df' command (file
> system disk space usage). Is there an equivalent Unix system call?

  http://www.gnu.org/software/coreutils/

Bob


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

"date" not validating correctly

[ianseeks]

Hi,

I have been unable to change date on my SuSE 8.2 system.  I've tried using the 
KDE utilities and they did not work so i tried "date --set 081313012003" on 
the command line and got this error  "date: invalid date `081321532003'.  I 
am in the UK using the UK date format.  Also note the different quote marks 
on the error message.

The version of date is :

date --version
date (coreutils) 4.5.8
Written by David MacKenzie.

Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


I hope this is some use, and i'm not going mad.  :o)

regards

Ian



___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: make check fix

[Simon Josefsson]

Paul Eggert <[EMAIL PROTECTED]> writes:

> Simon Josefsson <[EMAIL PROTECTED]> writes:
>
>> For some reason sort in LANG=sv_SE.UTF-8 sort 'w' equal to 'v', making
>> 'wc' end up before 'vdir', and a check fails.
>
> Thanks for pointing this out.  But the patch isn't quite right, since
> you can't portably set LC_COLLATE to C without also setting LC_CTYPE
> consistently, as the resulting behavior is undefined.  It's simpler
> just to set LC_ALL.  Also, there are some other places that have the
> same problem.  How about the following patch instead?

Looks better.  Thanks!



___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: bug in tr, version 4.5.3

[Bob Proulx]

Bob Proulx wrote:
> Try this instead:
> 
>   echo fdhrnzvfu bffvsentr | tr '[a-z]' '[n-za-m]'

Oops.  I should have said:

  echo fdhrnzvfu bffvsentr | tr a-z n-za-m

The STRINGS are already character classes so they don't need
brackets.  And with no brackets no need to quote.

Also, for a full rot13 don't forget the capital letters!  :-)

  echo fdhrnzvfu bffvsentr | tr A-Za-z N-ZA-Mn-za-m

Bob


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

date(1) treats TZ '' differently from unset

[Ed Avis]

On a system where local time is +0100:

% (unset TZ; date +%z)
+0100
% (TZ= date +%z)
+

Are you sure this is correct?  I would have expected the empty string
for TZ to act the same as having that variable unset, or otherwise to
produce a warning that TZ was set to a bad value.

% date --version
date (coreutils) 5.0
Written by David MacKenzie.

Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

-- 
Ed Avis <[EMAIL PROTECTED]>




___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

glibc utimes glitch with coreutils 'touch'

[Paul Eggert]

In 
Jim Meyering <[EMAIL PROTECTED]> writes:

> Here are the symptoms of the utimes failure I mentioned recently.

You're suffering from Debian bug 202243 ("utimes() broken"); see
.  The patch
proposed there won't entirely fix the bug, though, since it causes
'utimes' to round instead of truncate.  Historically, utimes truncated
when it couldn't store the microseconds, and the coreutils 'touch' code in

relies on this truncation.

I tried to find out why glibc changed from truncation to rounding.
Ulrich Drepper checked in a new Linux version of utimes on 2003-07-12,
to support newer Linux kernels that have utimes support.  On older
kernels this new code attempted to round, even though the usual
practice with timestamps is to truncate when going to a lower
resolution.  I don't know why rounding was introduced here.

(Personally I wish Linux would let me set the file's timestamp to the
nearest nanosecond, as that would avoid all this mess entirely.)

I'll submit an alternate patch to coreutils so that it works around
this glibc glitch.  The simplest workaround is to not invoke utimes
when building with glibc; perhaps I can improve on that, but I don't
know.

I propose the following patch to fix glibc:

2003-08-09  Paul Eggert  <[EMAIL PROTECTED]>

Revert to utimes's previous (i.e., pre-2003-07-12) behavior of
truncating fractional parts of timestamps that it can't use,
instead of attempting to round.
* sysdeps/unix/sysv/linux/utimes.c (__utimes):
Fix actime and modtime computation to truncate microseconds
rather than attempting to round.
* sysdeps/unix/sysv/linux/futimes.c (__futimes): Likewise.
* sysdeps/posix/utimes.c (__utimes): Likewise.

Index: sysdeps/unix/sysv/linux/utimes.c
===
RCS file: /cvs/glibc/libc/sysdeps/unix/sysv/linux/utimes.c,v
retrieving revision 1.3
diff -p -u -r1.3 utimes.c
--- sysdeps/unix/sysv/linux/utimes.c31 Jul 2003 19:04:13 -  1.3
+++ sysdeps/unix/sysv/linux/utimes.c10 Aug 2003 06:15:53 -
@@ -47,8 +47,8 @@ __utimes (const char *file, const struct
   if (tvp != NULL)
 {
   times = &buf;
-  buf.actime = tvp[0].tv_sec + (tvp[0].tv_usec + 50) / 100;
-  buf.modtime = tvp[1].tv_sec + (tvp[1].tv_usec + 50) / 100;
+  buf.actime = tvp[0].tv_sec + tvp[0].tv_usec / 100;
+  buf.modtime = tvp[1].tv_sec + tvp[1].tv_usec / 100;
 }
   else
 times = NULL;
Index: sysdeps/unix/sysv/linux/futimes.c
===
RCS file: /cvs/glibc/libc/sysdeps/unix/sysv/linux/futimes.c,v
retrieving revision 1.6
diff -p -u -r1.6 futimes.c
--- sysdeps/unix/sysv/linux/futimes.c   31 Jul 2003 19:04:13 -  1.6
+++ sysdeps/unix/sysv/linux/futimes.c   10 Aug 2003 06:15:53 -
@@ -58,8 +58,8 @@ __futimes (int fd, const struct timeval 
   if (tvp != NULL)
 {
   times = &buf;
-  buf.actime = tvp[0].tv_sec + (tvp[0].tv_usec + 50) / 100;
-  buf.modtime = tvp[1].tv_sec + (tvp[1].tv_usec + 50) / 100;
+  buf.actime = tvp[0].tv_sec + tvp[0].tv_usec / 100;
+  buf.modtime = tvp[1].tv_sec + tvp[1].tv_usec / 100;
 }
   else
 times = NULL;
Index: sysdeps/posix/utimes.c
===
RCS file: /cvs/glibc/libc/sysdeps/posix/utimes.c,v
retrieving revision 1.7
diff -p -u -r1.7 utimes.c
--- sysdeps/posix/utimes.c  31 Jul 2003 19:04:13 -  1.7
+++ sysdeps/posix/utimes.c  10 Aug 2003 06:15:53 -
@@ -31,8 +31,8 @@ __utimes (const char *file, const struct
   if (tvp)
 {
   times = &buf;
-  buf.actime = tvp[0].tv_sec + (tvp[0].tv_usec + 50) / 100;
-  buf.modtime = tvp[1].tv_sec + (tvp[1].tv_usec + 50) / 100;
+  buf.actime = tvp[0].tv_sec + tvp[0].tv_usec / 100;
+  buf.modtime = tvp[1].tv_sec + tvp[1].tv_usec / 100;
 }
   else
 times = NULL;


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Problem with tail

[Fritz_Schenk]

The problem I have with tail manifests itself when the total number of bytes in a file exceeds 2147483648. 

Thank you___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: [patch] Adding Numerical Suffixes to Split

[Jim Meyering]

Paul Eggert <[EMAIL PROTECTED]> wrote:
> How about this patch instead?  It fixes a couple of minor
> POSIX-compliance bugs in split, while I was in the neighborhood.
>
> 2003-08-07  Paul Eggert  <[EMAIL PROTECTED]>
>
> * doc/coreutils.texi (split invocation):
>   Add -d or --numeric-suffixes option to 'split'.
> From a suggestion by Jesse Kornblum.
>   * src/split.c (suffix_alphabet): New var.
> (longopts, usage, next_file_name, main): Support -d.
> (next_file_name, main): Allow -a0, as POSIX requires.
> (next_file_name): Don't assume ASCII-like encoding;
>   'a' through 'z' are not contiguous in EBCDIC.

Thanks!
I've applied that.

However, I have my doubts about allowing -a0.
Do you see any practical value in that?
It makes split degenerate to `cp', but with the
limitation that it fails if there is too much input.
Hmm... when now that I've written the preceding sentence,
I *can* imagine a use for it :-)

I've fixed the test (tests/misc/split-fail), too.


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: Suggestion for split.c

[Paul Eggert]

"Galbraith, Mark" <[EMAIL PROTECTED]> writes:

> My suggestion is to use an option like "-H n" (or other option
> letter as may be determined by the maintainer of split.c) to specify
> the number of rows that constitute the "Header" of the source file. 
> A maximum number of rows would be need to be determined.

No, the general GNU philosophy is that there should be no arbitrary limit.
Just xmalloc as much space as you need.

Some comments:

Shouldn't 'n' count bytes (not lines) if the -C or -b option is used?

I assume the operands of -b, -C, and -l include the output headers in
size calculations?  If so, what if the header size is greater than the
sizes indicated by those operands?

Is there a similar need for a file tail option?  If not, why not?

And last but not least -- is this functionality really appropriate for
a low-level bulk tool like 'split'?  One might argue that it's more
appropriate to write a Python or Perl script


> Pointers to any list archives would be appreciated.

You can see previous posts at:

http://mail.gnu.org/archive/html/bug-coreutils/


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

wait4 - proposed new program

[Martin von Gagern]

Hello!

I'm proposing a little program, let's call it "wait4", maybe to one day
become part of the coreutils.

Basically that thing should monitor files listed as arguments and
terminate successfully as soon as one is changed.
For example:
 while wait4 program.c *.h; do make program && ./program; done
So I could edit the code in my favorite editor, and as soon as I save my
changes, the thing is recompiled.

I've written a first version of this for myself, simply polling for the
filenames every second and comparing the mtime. Given some time, I'd
like to do some additions listed below.

I believe this tool to be useful enough to be made available to the
public, but too small to be a standalone package. So I thought perhaps
it should be part of coreutils. What do you think?

BTW: Do you know anything like this around? I found nothing, but because
this could be phrased in so many different ways and could always be part
of a larger package, that accounts for nothing.

Additions I have in mind:
- handling of standard options (--help, --version)
- configurable polling interval
- configurable handling of files being / becoming nonexistent
- successful termination on input on stdin (manual trigger)
- selection of which stat fields are being watched
- integration of FAM API where available

The last could be a problem for the order in which the utilities are
built from source, as building FAM might require the existence of the
coreutils, so wait4 would have to be compiled twice.
Is this reason enough not to make it a part of coreutils?

See also http://oss.sgi.com/projects/fam/

I would appreciate your opinions.
Thanx,
 Martin


pgp0.pgp
Description: PGP signature
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Suggestion for split.c

[Galbraith, Mark]

First, let me 
preface this by saying that I'm a new list member, and have not seen any 
previous posts made to this list.  If this, or something similar, has 
already been posted and discussed, please forgive me.  Pointers to any list 
archives would be appreciated.
 
I have a suggestion 
for a new option and function for the split(1) program.  I would like to 
explore adding the capability to specify a number of rows from the top of the 
source file that will be COPIED to the start of each file produced by 
split(1).  
 
As an example,  
I have a file that contains 10,000 rows, the first line being a header 
row.  I want to split this file into files that contain 1,000 rows each, 
but I want each output file to also start with the header 
row.
 
I realize that this 
would invalidate one of the nice features of the current versions of 
split(1).  That being that a "Split" file can always be reconstructed using 
cat(1).  As the default operation of split(1) would be to continue the 
current method (no header row copying), I think this "feature" is 
safe.
 
My suggestion is to 
use an option like "-H n" (or other option letter as may be determined by the 
maintainer of split.c) to specify the number of rows that constitute the 
"Header" of the source file.  A maximum number of rows would be need to be 
determined.  I suggest a maximum of 256 lines.  While the file is 
first being processed, these lines can be copied into a malloc'd buffer that 
would be output to the new files created.
 
I'm sure the design 
and coding of this will be a topic for discussion as we refine the requirement 
and design.  I'm very willing to perform the design and coding of this 
change, however I wanted to discuss the change here first.  Please let me 
know if you have any questions.
 

-- 
Mark Galbraith
Managed Services Team Leader
Data Return 
LLC
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

gnuwin32 packages, sh-utils, tool su

[Daniel Wapenaar]

Hi 

I want to use the tool su but I can't find it in the binary package 
sh-utils-2.0-bin.zip ??
Is it generally supported for a windows system? Is there an alternative?

package: sh-utils 
version: 2.0

thanks in advance for a quick answer
Dani


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils