From R.E.Wolff at BitWizard.nl  Fri Aug  8 17:20:07 2008
From: R.E.Wolff at BitWizard.nl (Rogier Wolff)
Date: Fri, 8 Aug 2008 16:20:07 +0200
Subject: ls-F output wraps. 
Message-ID: <20080808142007.GA16520@bitwizard.nl>


Hi, 


Since a while, apparently (especially when there are short names
involved) ls-F will calculate the total required space for <n> colums
too small. This causes the columns that are supposed to fit
on one line to wrap. This is ugly. 

For my testrun my window was 80 wide. The cut-paste inserted the
newlines you find in this Email message, which is in this case
exactly what I want. (to show you the problem.)

I've been annoyed at this problem for a while now, but hadn't 
gotten around to figuring out what was wrong. Turns out it is 
not "gnu coreutils" that is wrong, but the tcsh-builtin. This
leaves me with an easy workaround: use the external ls. 

zebigbos:..../collinks> /bin/ls -F
0/    13c/  188/  1dc/  22c/  28/   2cc/  31c/  368/  3ac/  3f4/  7c/  c4/
10/   14/   18c/  1e0/  230/  280/  2d0/  31e/  36c/  3b0/  3f8/  8/   c8/
100/  140/  190/  1e4/  234/  284/  2d2/  320/  370/  3b2/  3fc/  80/  cc/
[...]
zebigbos:..../collinks> ls-F
0/    132/  170/  1b0/  1f8/  238/  27c/  2c/   30/   34/   38/   3b2/  3ec/  6c
/   a8/   e6/
10/   134/  174/  1b4/  1fc/  23c/  28/   2c0/  300/  340/  380/  3b4/  3f0/  70
/   ac/   e8/
100/  138/  178/  1b8/  1fe/  24/   280/  2c4/  304/  342/  384/  3b8/  3f4/  72
/   b0/   ec/
[...]
zebigbos:..../collinks> 

Regards, 

	Roger.

-- 
** R.E.Wolff at BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ


From R.E.Wolff at BitWizard.nl  Fri Aug  8 18:32:43 2008
From: R.E.Wolff at BitWizard.nl (Rogier Wolff)
Date: Fri, 8 Aug 2008 17:32:43 +0200
Subject: ls-F output wraps.
Message-ID: <20080808153243.GA4670@bitwizard.nl>


Hi,

I thought it couldn't be difficult.... 

So I fixed it. 

I thought the problem might be related to the fact that I disabled the
color listings. However, I cannot reproduce turning the colors back
on. Apparently I've got it convinced that I don't like colors.

Anyway, without the below patch, 

	w = (unsigned int) NLSStringWidth(items[i]) + wx;

on line 2112 of tw.parse.c counts one character less than actually
output. So it counts "3" chars for my example case. Because "maxwidth"
was correctly calculated to be 5 (in this case 4+1, and not the
expected 3+2), the loop on lines 2113 and 2114 outputs two extra
spaces, where only one is expected/required.....

	Roger.


--- rew/tcsh-6.14.00/tw.parse.c	2005-03-03 17:40:53.000000000 +0100
+++ tcsh-6.14.00/tw.parse.c	2008-08-08 17:13:56.000000000 +0200
@@ -2088,6 +2088,7 @@
 		    Char f = items[i][w - 1];
 		    items[i][w - 1] = 0;
 		    print_with_color(items[i], w - 1, f);
+		    items[i][w - 1] = f;
 		}
 		else {
 		    /* Print filename followed by '/' or '*' or ' ' */

-- 
** R.E.Wolff at BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ


From RKLeonard at raytheon.com  Sat Aug  9 16:01:17 2008
From: RKLeonard at raytheon.com (Kent Leonard)
Date: Sat, 9 Aug 2008 08:01:17 -0500
Subject: Kent Leonard/US/Raytheon is out of the office 
Message-ID: <OF28927339.C8ECCEF3-ON862574A0.00478779-862574A0.00478779@mck.us.ray.com>


I will be out of the office starting  08/05/2008 and will not return until
08/11/2008.


 .


From R.E.Wolff at BitWizard.nl  Tue Aug 12 09:08:15 2008
From: R.E.Wolff at BitWizard.nl (Rogier Wolff)
Date: Tue, 12 Aug 2008 08:08:15 +0200
Subject: ls-F output wraps.
Message-ID: <20080812060815.GA20605@bitwizard.nl>


Hi,

I sent a bugreport together with a fix, but didn't hear from it
anymore, so I'm suspecting that the moderator is dropping mail from
non-subscribers in a bulk mode, because most of it is spam anyway.
The promised "rejection" or "accpetance" notice never came. 


Here is the report: 


Since a while, apparently (especially when there are short names
involved) ls-F will calculate the total required space for <n> colums
too small. This causes the columns that are supposed to fit on one
line to wrap. This is ugly.

For my testrun my window was 80 wide. The cut-paste inserted the
newlines you find in this Email message, which is in this case
exactly what I want. (to show you the problem.)

I've been annoyed at this problem for a while now, but hadn't
gotten around to figuring out what was wrong. Turns out it is
not "gnu coreutils" that is wrong, but the tcsh-builtin.

zebigbos:..../collinks> /bin/ls -F
0/    13c/  188/  1dc/  22c/  28/   2cc/  31c/  368/  3ac/  3f4/  7c/  c4/
10/   14/   18c/  1e0/  230/  280/  2d0/  31e/  36c/  3b0/  3f8/  8/   c8/
100/  140/  190/  1e4/  234/  284/  2d2/  320/  370/  3b2/  3fc/  80/  cc/
[...]
zebigbos:..../collinks> ls-F
0/    132/  170/  1b0/  1f8/  238/  27c/  2c/   30/   34/   38/   3b2/  3ec/  6c
/   a8/   e6/
10/   134/  174/  1b4/  1fc/  23c/  28/   2c0/  300/  340/  380/  3b4/  3f0/  70
/   ac/   e8/
100/  138/  178/  1b8/  1fe/  24/   280/  2c4/  304/  342/  384/  3b8/  3f4/  72
/   b0/   ec/
[...]
zebigbos:..../collinks>


So I fixed it.

I thought the problem might be related to the fact that I disabled the
color listings. However, I cannot reproduce turning the colors back
on. Apparently I've got it convinced that I don't like colors.

Anyway, without the below patch,

        w = (unsigned int) NLSStringWidth(items[i]) + wx;

on line 2112 of (my version of) tw.parse.c counts one character less
than actually output. So it counts "3" chars for my example
case. Because "maxwidth" was correctly calculated to be 5 (in this
case 4+1, and not the expected 3+2), the loop on lines 2113 and 2114
outputs two extra spaces, where only one is expected/required.....

I now see that /bin/ls outputs TWO spaces between each of the columns,
while as far as I can see the tcsh code was intended to output ONE
space between columns. So that's what I made it do, but it was also
intended to mimic /bin/ls behaviour....

        Roger.


--- rew/tcsh-6.14.00/tw.parse.c 2005-03-03 17:40:53.000000000 +0100
+++ tcsh-6.14.00/tw.parse.c     2008-08-08 17:13:56.000000000 +0200
@@ -2088,6 +2088,7 @@
                    Char f = items[i][w - 1];
                    items[i][w - 1] = 0;
                    print_with_color(items[i], w - 1, f);
+                   items[i][w - 1] = f;
                }
                else {
                    /* Print filename followed by '/' or '*' or ' ' */



-- 
** R.E.Wolff at BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ


From kim at tcsh.org  Tue Aug 12 09:31:50 2008
From: kim at tcsh.org (Kimmo Suominen)
Date: Tue, 12 Aug 2008 09:31:50 +0300
Subject: ls-F output wraps.
In-Reply-To: <20080812060815.GA20605@bitwizard.nl>
References: <20080812060815.GA20605@bitwizard.nl>
Message-ID: <20080812063150.GS5954@kimmo.suominen.com>

On Tue, Aug 12, 2008 at 08:08:15AM +0200, Rogier Wolff wrote:
> 
> Hi,
> 
> I sent a bugreport together with a fix, but didn't hear from it
> anymore, so I'm suspecting that the moderator is dropping mail from
> non-subscribers in a bulk mode, because most of it is spam anyway.
> The promised "rejection" or "accpetance" notice never came. 

Your messages were approved.  The moderator reads all submissions and
rejects spam, but not bug reports.  The moderator can also be reached by
email, as advertised at the bottom of the list information page, so it
is possible to ask and check about your submission.

    http://mx.gw.com/mailman/listinfo/tcsh-bugs

Then there is also the mailing list archive, which is likewise linked
from the list information page.  The archive for August 2008 shows all
three of your messages.

    http://mx.gw.com/pipermail/tcsh-bugs/2008-August/thread.html

If you are not subscribed to the list, you won't receive messages sent
to it (which should be obvious).  However, the list is configured so
that no reply-to header is added, which should preserve the sender's
address when using a group reply (reply to all) function.

There have been no replies as of yet to your other messages, at least
not so that the list would have been kept in the recipients.

I wasn't aware of an acceptance notice being promised anywhere.  If you
can point me towards the promise (e.g. send me a copy or link in private
mail), I can check to see if I can reword such promise to match the
actual functioning of Mailman.

Best regards,
+ Kimmo (the moderator)
-- 
<A HREF="http://kimmo.suominen.com/">Kimmo Suominen</A>


From christos at zoulas.com  Tue Aug 12 11:16:28 2008
From: christos at zoulas.com (Christos Zoulas)
Date: Tue, 12 Aug 2008 04:16:28 -0400
Subject: ls-F output wraps.
In-Reply-To: <20080812060815.GA20605@bitwizard.nl>
	from Rogier Wolff (Aug 12,  8:08am)
Message-ID: <20080812081628.2DBC35654F@rebar.astron.com>

On Aug 12,  8:08am, R.E.Wolff at BitWizard.nl (Rogier Wolff) wrote:
-- Subject: Re: ls-F output wraps.

| 
| Hi,
| 
| I sent a bugreport together with a fix, but didn't hear from it
| anymore, so I'm suspecting that the moderator is dropping mail from
| non-subscribers in a bulk mode, because most of it is spam anyway.
| The promised "rejection" or "accpetance" notice never came. 
| 
| 
| Here is the report: 
| 
| 
| Since a while, apparently (especially when there are short names
| involved) ls-F will calculate the total required space for <n> colums
| too small. This causes the columns that are supposed to fit on one
| line to wrap. This is ugly.
| 
| For my testrun my window was 80 wide. The cut-paste inserted the
| newlines you find in this Email message, which is in this case
| exactly what I want. (to show you the problem.)
| 
| I've been annoyed at this problem for a while now, but hadn't
| gotten around to figuring out what was wrong. Turns out it is
| not "gnu coreutils" that is wrong, but the tcsh-builtin.
| 
| zebigbos:..../collinks> /bin/ls -F
| 0/    13c/  188/  1dc/  22c/  28/   2cc/  31c/  368/  3ac/  3f4/  7c/  c4/
| 10/   14/   18c/  1e0/  230/  280/  2d0/  31e/  36c/  3b0/  3f8/  8/   c8/
| 100/  140/  190/  1e4/  234/  284/  2d2/  320/  370/  3b2/  3fc/  80/  cc/
| [...]
| zebigbos:..../collinks> ls-F
| 0/    132/  170/  1b0/  1f8/  238/  27c/  2c/   30/   34/   38/   3b2/  3ec/  6c
| /   a8/   e6/
| 10/   134/  174/  1b4/  1fc/  23c/  28/   2c0/  300/  340/  380/  3b4/  3f0/  70
| /   ac/   e8/
| 100/  138/  178/  1b8/  1fe/  24/   280/  2c4/  304/  342/  384/  3b8/  3f4/  72
| /   b0/   ec/
| [...]
| zebigbos:..../collinks>
| 
| 
| So I fixed it.
| 
| I thought the problem might be related to the fact that I disabled the
| color listings. However, I cannot reproduce turning the colors back
| on. Apparently I've got it convinced that I don't like colors.
| 
| Anyway, without the below patch,
| 
|         w = (unsigned int) NLSStringWidth(items[i]) + wx;
| 
| on line 2112 of (my version of) tw.parse.c counts one character less
| than actually output. So it counts "3" chars for my example
| case. Because "maxwidth" was correctly calculated to be 5 (in this
| case 4+1, and not the expected 3+2), the loop on lines 2113 and 2114
| outputs two extra spaces, where only one is expected/required.....
| 
| I now see that /bin/ls outputs TWO spaces between each of the columns,
| while as far as I can see the tcsh code was intended to output ONE
| space between columns. So that's what I made it do, but it was also
| intended to mimic /bin/ls behaviour....
| 
|         Roger.
| 
| 
| --- rew/tcsh-6.14.00/tw.parse.c 2005-03-03 17:40:53.000000000 +0100
| +++ tcsh-6.14.00/tw.parse.c     2008-08-08 17:13:56.000000000 +0200
| @@ -2088,6 +2088,7 @@
|                     Char f = items[i][w - 1];
|                     items[i][w - 1] = 0;
|                     print_with_color(items[i], w - 1, f);
| +                   items[i][w - 1] = f;
|                 }
|                 else {
|                     /* Print filename followed by '/' or '*' or ' ' */
| 
| 

Thanks, but this bug has been fixed a long time ago:

3.106        (kim      11-Apr-05):                  items[i][w - 1] = f;

and the fix is still present in the current version of tcsh (6.15).

Best,

christos


From R.E.Wolff at BitWizard.nl  Tue Aug 12 13:05:06 2008
From: R.E.Wolff at BitWizard.nl (Rogier Wolff)
Date: Tue, 12 Aug 2008 12:05:06 +0200
Subject: ls-F output wraps.
In-Reply-To: <20080812081628.2DBC35654F@rebar.astron.com>
References: <20080812060815.GA20605@bitwizard.nl>
	<20080812081628.2DBC35654F@rebar.astron.com>
Message-ID: <20080812100506.GA6752@bitwizard.nl>

On Tue, Aug 12, 2008 at 04:16:28AM -0400, Christos Zoulas wrote:
> On Aug 12,  8:08am, R.E.Wolff at BitWizard.nl (Rogier Wolff) wrote:
> Thanks, but this bug has been fixed a long time ago:
> 
> 3.106        (kim      11-Apr-05):                  items[i][w - 1] = f;
> 
> and the fix is still present in the current version of tcsh (6.15).

Ah. Ok, I'm using 6.14, released two weeks earlier. 

	Roger. 

-- 
** R.E.Wolff at BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ


From rabbe.fogelholm at era-t.ericsson.se  Fri Aug 15 09:48:04 2008
From: rabbe.fogelholm at era-t.ericsson.se (Rabbe Fogelholm)
Date: Fri, 15 Aug 2008 08:48:04 +0200
Subject: LS_COLORS code "rs" should be listed in the tcsh manpage
Message-ID: <48A526A4.6090309@era-t.ericsson.se>

The dircolors program (part of GNU coreutils) can generate an LS_COLORS code "rs=0". 
This code was added 2008-02-17, see here (look for the "Adjust dircolors to match 
ls.c" entry):

http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=history;f=src/dircolors.c;h=79109b93455762f988c79eca44ea31ada455dd8a;hb=HEAD

Recent versions of tcsh seem to accept this code (whereas e. g. 6.14.00 complains 
"Unknown colorls variable `rs'").

Since this code is now accepted it should perhaps be listed in the tcsh manpage, 
under ENVIRONMENT, LS_COLORS.


From mikets at frontline-pcb.com  Sun Aug 17 17:32:51 2008
From: mikets at frontline-pcb.com (Michael Tseitlin)
Date: Sun, 17 Aug 2008 17:32:51 +0300
Subject: Intermittent tcsh crashes on Windows
Message-ID: <830C82B0B852B9488F0A944853D4D01204F7593C@uganda.FRONTLINE-PCB.COM>

Hi,
 
I experience intermittent crashes of tcsh - using 6.15.
 
Unfortunately, I can't reproduce the problem with a specific command
line - but usually it takes me few minutes to run our scripting system
to get an error.
 
After some debugging I've get to error messages coming out of free()
(tc.alloc.c) - different kinds of messages from the checks there - I
conclude that some memory is corrupted.
 
When running with Purify, I get the following partial report:
 
[E] IPW: Invalid pointer write in short2str {5186 occurrences}
        Writing 1 byte to 0x7fbb7808 (1 byte at 0x7fbb7808 illegal)
        Address 0x7fbb7808 points into a committed VirtualAlloc'd block 
        Thread ID: 0x13d0
        Error location
            short2str      [tc.str.c:169]
            short2blk      [tc.str.c:128]
            fork           [fork.c:237]
                        restore_fds();
                
                        STR_environ = blk2short(environ);
             =>         environ = short2blk(STR_environ);    /* So that
we can free it */
                
                        return 0;
                    }
            nt_init        [support.c:96]
            main           [sh.c:182]
            _tmainCRTStartup [crt0.c:327]
            mainCRTStartup [crt0.c:195]
            silly_entry    [support.c:725]
[E] IPW: Invalid pointer write in short2str {105 occurrences}
[E] IPR: Invalid pointer read in strlen {105 occurrences}
[E] IPR: Invalid pointer read in memcpy {105 occurrences}
[E] IPR: Invalid pointer read in pfork {1 occurrence}
        Reading 4 bytes from 0x7fc1e924 (4 bytes at 0x7fc1e924 illegal)
        Address 0x7fc1e924 points into a committed VirtualAlloc'd block 
        Thread ID: 0x13d0
        Error location
            pfork          [sh.proc.c:1756]
                    (void)cleanup_push_mark(); /* Never to be popped */
                    pchild_disabled = 0;
                    settimes();
             =>     pgrp = pcurrjob ? pcurrjob->p_jobid : getpid();
                    pflushall();
                    pcurrjob = NULL;
                #if !defined(BSDTIMES) && !defined(_SEQUENT_)
            main           [sh.c:182]
            _tmainCRTStartup [crt0.c:327]
            mainCRTStartup [crt0.c:195]
            silly_entry    [support.c:725]
[E] IPR: Invalid pointer read in pflushall {2 occurrences}
 
Can it somehow point to problems?

By another observation I can think that the problem can be caused by
threading conflict etc. Can it be correct?
 
I'd like to solve the problem and ready to do checks etc. that you guys
will suggest.
 
Thanks,
 
Michael
 

 


From macro at linux-mips.org  Sat Aug 23 23:07:02 2008
From: macro at linux-mips.org (Maciej W. Rozycki)
Date: Sat, 23 Aug 2008 21:07:02 +0100 (BST)
Subject: 6.15.00: `config.rpath' missing
Message-ID: <Pine.LNX.4.55.0808232047300.6466@cliff.in.clinika.pl>

Hello,

 The current tcsh release tarball does not contain the `config.rpath'
script.  The script is a part of the gettext package and is invoked by the
AC_LIB_RPATH autoconf macro which is referred to from the expansion of the
AM_ICONV macro tcsh uses.  The following error results when `configure' is
run:

checking if the linker (/usr/mips64-linux/bin/ld) is GNU ld... yes
checking for shared library run path origin... /bin/sh: ./config.rpath: No such file or directory
done
checking for iconv... yes

 The fix is to install `config.rpath' alongside `config.guess',
`config.sub', etc.  This can be done by running `gettextize --copy' (this
installs all the gettext files; use with --force to update older ones
already in place) or manually -- the script is normally installed with
gettext in ${datadir}/gettext/.

  Maciej


From christos at zoulas.com  Wed Aug 27 13:26:17 2008
From: christos at zoulas.com (Christos Zoulas)
Date: Wed, 27 Aug 2008 06:26:17 -0400
Subject: 6.15.00: `config.rpath' missing
In-Reply-To: <Pine.LNX.4.55.0808232047300.6466@cliff.in.clinika.pl>
	from "Maciej W. Rozycki" (Aug 23,  9:07pm)
Message-ID: <20080827102618.0E3DF5654E@rebar.astron.com>

On Aug 23,  9:07pm, macro at linux-mips.org ("Maciej W. Rozycki") wrote:
-- Subject: 6.15.00: `config.rpath' missing

| Hello,
| 
|  The current tcsh release tarball does not contain the `config.rpath'
| script.  The script is a part of the gettext package and is invoked by the
| AC_LIB_RPATH autoconf macro which is referred to from the expansion of the
| AM_ICONV macro tcsh uses.  The following error results when `configure' is
| run:
| 
| checking if the linker (/usr/mips64-linux/bin/ld) is GNU ld... yes
| checking for shared library run path origin... /bin/sh: ./config.rpath: No such file or directory
| done
| checking for iconv... yes
| 
|  The fix is to install `config.rpath' alongside `config.guess',
| `config.sub', etc.  This can be done by running `gettextize --copy' (this
| installs all the gettext files; use with --force to update older ones
| already in place) or manually -- the script is normally installed with
| gettext in ${datadir}/gettext/.

What installs gettextsize?

christos


From macro at linux-mips.org  Wed Aug 27 19:15:13 2008
From: macro at linux-mips.org (Maciej W. Rozycki)
Date: Wed, 27 Aug 2008 17:15:13 +0100 (BST)
Subject: 6.15.00: `config.rpath' missing
In-Reply-To: <20080827102618.0E3DF5654E@rebar.astron.com>
References: <20080827102618.0E3DF5654E@rebar.astron.com>
Message-ID: <Pine.LNX.4.55.0808271708280.5930@cliff.in.clinika.pl>

On Wed, 27 Aug 2008, Christos Zoulas wrote:

> |  The fix is to install `config.rpath' alongside `config.guess',
> | `config.sub', etc.  This can be done by running `gettextize --copy' (this
> | installs all the gettext files; use with --force to update older ones
> | already in place) or manually -- the script is normally installed with
> | gettext in ${datadir}/gettext/.
> 
> What installs gettextsize?

 It comes with gettext.  Watch the spelling -- it's gettextize!  It's full
description is referred to from the main gettext info page in the "The
Maintainer's View" section.

  Maciej


From christos at zoulas.com  Wed Aug 27 21:07:29 2008
From: christos at zoulas.com (Christos Zoulas)
Date: Wed, 27 Aug 2008 14:07:29 -0400
Subject: 6.15.00: `config.rpath' missing
In-Reply-To: <Pine.LNX.4.55.0808271708280.5930@cliff.in.clinika.pl>
	from "Maciej W. Rozycki" (Aug 27,  5:15pm)
Message-ID: <20080827180729.D932C5654F@rebar.astron.com>

On Aug 27,  5:15pm, macro at linux-mips.org ("Maciej W. Rozycki") wrote:
-- Subject: Re: 6.15.00: `config.rpath' missing

| On Wed, 27 Aug 2008, Christos Zoulas wrote:
| 
| > |  The fix is to install `config.rpath' alongside `config.guess',
| > | `config.sub', etc.  This can be done by running `gettextize --copy' (this
| > | installs all the gettext files; use with --force to update older ones
| > | already in place) or manually -- the script is normally installed with
| > | gettext in ${datadir}/gettext/.
| > 
| > What installs gettextsize?
| 
|  It comes with gettext.  Watch the spelling -- it's gettextize!  It's full
| description is referred to from the main gettext info page in the "The
| Maintainer's View" section.

What version of gettext? It is seems not to be in 0.14.4 which NetBSD currently
has. Finally it seems wrong to me to depend on a particular iconv installation
to grab autoconf features for it. This does not belong in gettext, but in
autoconf. How does solaris and other !linux OS's handle this?

christos


From macro at linux-mips.org  Thu Aug 28 01:33:01 2008
From: macro at linux-mips.org (Maciej W. Rozycki)
Date: Wed, 27 Aug 2008 23:33:01 +0100 (BST)
Subject: 6.15.00: `config.rpath' missing
In-Reply-To: <20080827180729.D932C5654F@rebar.astron.com>
References: <20080827180729.D932C5654F@rebar.astron.com>
Message-ID: <Pine.LNX.4.55.0808272231530.5930@cliff.in.clinika.pl>

On Wed, 27 Aug 2008, Christos Zoulas wrote:

> |  It comes with gettext.  Watch the spelling -- it's gettextize!  It's full
> | description is referred to from the main gettext info page in the "The
> | Maintainer's View" section.
> 
> What version of gettext? It is seems not to be in 0.14.4 which NetBSD currently

 It's been there at least since 0.10.35 which is the oldest version I have
ever dealt with.  I do not have older versions handy.  It looks like the
NetBSD installation is incomplete then.  Myself, I tend to build software
from sources, so I end up with whatever the respective maintainer of a
piece of software decided should be installed.

 Anyway, you can copy config.rpath manually.  If that is not installed
either, then you can extract it from a gettext source distribution.  
After all, it is merely a shell script -- no rocket science here.
I reckon this config.rpath script to be a fairly recent addition.

> has. Finally it seems wrong to me to depend on a particular iconv installation
> to grab autoconf features for it. This does not belong in gettext, but in

 This is an autoconf extension, so it cannot come with autoconf proper.  
You are right though that AM_ICONV should not depend on the
system-installed locale support and to the best of my knowledge that is
indeed the intent.  The user does not have to have gettext installed for
compilation to work.

 However the AM_ICONV implementation you have chosen actually comes with
gettext and I think its assumption for a software package maintainer to
have the rest of gettext installed too is not unreasonable.

> autoconf. How does solaris and other !linux OS's handle this?

 I have no access to such systems anymore, sorry.  However as I understand
the behaviour is essentially the same: if there is locale support
installed in the system and its functionality is good enough as determined
by the autoconf macro, then it is used, otherwise the library bundled with
the software package is built and used instead (unless --disable-nls is
specified).

 As I understand config.rpath is used to handle the case where a 
non-standard system-installed locale support library is in a place, such 
as /usr/local/lib, where it is not normally searched by the run-time 
loader; in this case a system-specific flag is passed through to the 
static loader so as to add the necessary library search path to the 
binary being linked against the library.  The purpose of the script is to 
produce the flag needed.

 Please note that while I have some experience with some pieces of 
software I do not claim authority on gettext -- please consider discussing 
any concerns with gettext maintainers at <bug-gnu-gettext at gnu.org>.  Feel 
free to cc me if you believe I might provide any insight.

  Maciej


From mikets at frontline-pcb.com  Sun Aug 31 14:46:51 2008
From: mikets at frontline-pcb.com (Michael Tseitlin)
Date: Sun, 31 Aug 2008 14:46:51 +0300
Subject: Intermittent tcsh crashes on Windows
In-Reply-To: <mailman.3.1219050002.16889.tcsh-bugs@mx.gw.com>
References: <mailman.3.1219050002.16889.tcsh-bugs@mx.gw.com>
Message-ID: <830C82B0B852B9488F0A944853D4D0120509A5C7@uganda.FRONTLINE-PCB.COM>

Hi,

I'm hate to push, but is there a chance to get some opinion?
I'm ready to get on with debugging but I'd like to hear some directions
from gurus.

Thanks,

Michael
 

-----Original Message-----
From: tcsh-bugs-bounces at mx.gw.com [mailto:tcsh-bugs-bounces at mx.gw.com]
On Behalf Of tcsh-bugs-request at mx.gw.com
Sent: Monday, August 18, 2008 12:00 PM
To: tcsh-bugs at mx.gw.com
Subject: Tcsh-Bugs Digest, Vol 48, Issue 6

Send Tcsh-Bugs mailing list submissions to
	tcsh-bugs at mx.gw.com

To subscribe or unsubscribe via the World Wide Web, visit
	http://mx.gw.com/mailman/listinfo/tcsh-bugs
or, via email, send a message with subject or body 'help' to
	tcsh-bugs-request at mx.gw.com

You can reach the person managing the list at
	tcsh-bugs-owner at mx.gw.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Tcsh-Bugs digest..."


Today's Topics:

   1. Intermittent tcsh crashes on Windows (Michael Tseitlin)


----------------------------------------------------------------------

Message: 1
Date: Sun, 17 Aug 2008 17:32:51 +0300
From: "Michael Tseitlin" <mikets at frontline-pcb.com>
Subject: Intermittent tcsh crashes on Windows
To: <tcsh-bugs at mx.gw.com>
Cc: Roven Tesler <roven at frontline-pcb.com>
Message-ID:
	
<830C82B0B852B9488F0A944853D4D01204F7593C at uganda.FRONTLINE-PCB.COM>
Content-Type: text/plain;	charset="us-ascii"

Hi,
 
I experience intermittent crashes of tcsh - using 6.15.
 
Unfortunately, I can't reproduce the problem with a specific command
line - but usually it takes me few minutes to run our scripting system
to get an error.
 
After some debugging I've get to error messages coming out of free()
(tc.alloc.c) - different kinds of messages from the checks there - I
conclude that some memory is corrupted.
 
When running with Purify, I get the following partial report:
 
[E] IPW: Invalid pointer write in short2str {5186 occurrences}
        Writing 1 byte to 0x7fbb7808 (1 byte at 0x7fbb7808 illegal)
        Address 0x7fbb7808 points into a committed VirtualAlloc'd block 
        Thread ID: 0x13d0
        Error location
            short2str      [tc.str.c:169]
            short2blk      [tc.str.c:128]
            fork           [fork.c:237]
                        restore_fds();
                
                        STR_environ = blk2short(environ);
             =>         environ = short2blk(STR_environ);    /* So that
we can free it */
                
                        return 0;
                    }
            nt_init        [support.c:96]
            main           [sh.c:182]
            _tmainCRTStartup [crt0.c:327]
            mainCRTStartup [crt0.c:195]
            silly_entry    [support.c:725]
[E] IPW: Invalid pointer write in short2str {105 occurrences}
[E] IPR: Invalid pointer read in strlen {105 occurrences}
[E] IPR: Invalid pointer read in memcpy {105 occurrences}
[E] IPR: Invalid pointer read in pfork {1 occurrence}
        Reading 4 bytes from 0x7fc1e924 (4 bytes at 0x7fc1e924 illegal)
        Address 0x7fc1e924 points into a committed VirtualAlloc'd block 
        Thread ID: 0x13d0
        Error location
            pfork          [sh.proc.c:1756]
                    (void)cleanup_push_mark(); /* Never to be popped */
                    pchild_disabled = 0;
                    settimes();
             =>     pgrp = pcurrjob ? pcurrjob->p_jobid : getpid();
                    pflushall();
                    pcurrjob = NULL;
                #if !defined(BSDTIMES) && !defined(_SEQUENT_)
            main           [sh.c:182]
            _tmainCRTStartup [crt0.c:327]
            mainCRTStartup [crt0.c:195]
            silly_entry    [support.c:725]
[E] IPR: Invalid pointer read in pflushall {2 occurrences}
 
Can it somehow point to problems?

By another observation I can think that the problem can be caused by
threading conflict etc. Can it be correct?
 
I'd like to solve the problem and ready to do checks etc. that you guys
will suggest.
 
Thanks,
 
Michael
 

 



------------------------------

_______________________________________________
Tcsh-Bugs mailing list
Tcsh-Bugs at mx.gw.com
http://mx.gw.com/mailman/listinfo/tcsh-bugs


End of Tcsh-Bugs Digest, Vol 48, Issue 6
****************************************