From ota at surfvi.com  Sat Oct  3 04:29:45 2009
From: ota at surfvi.com (Ted Anderson)
Date: Fri,  2 Oct 2009 21:29:45 -0400
Subject: Truncated history file after network crash
Message-ID: <20091002212945.qgwkg8gkw84ks80c@my.surfvi.com>

I've found an fairly serious bug that can cause the history file to be
truncated to zero length.  I've seen the problem reproducibly when tcsh
is running on a pseudo-terminal (pty) and terminates because the pty
master exits.  Apparently, the pty specification calls for the owner of
the slave side to receive a SIGHUP when the pty is closed, such as when
the master exits.  In response to the signal, tcsh starts trying to save
its history to the file, but this is interrupted immediately after the
file is opened (with O_TRUNC) leaving the user with an empty history
file.  In practical terms, this means that when running tcsh under
telnet, ssh, xterm and presumably numerous other such programs, an
unplanned failure, such as a network outage or X server crash, causes
the tcsh process to clear the history file when it exits.

I was able to reproduce this problem pretty easily with xterm and
confirmed that the problem did not affect version 6.14 that comes with
Ubuntu 8.04 or RHEL5.3.  Experiments with various recent versions of
tcsh[1] showed that the problem was introduced in version 6.15 and
affects all later versions.

Some debugging and study of the code explained the cause.  New signal
queuing logic was introduced in 6.15 and allows the signal handlers to
be run explicitly by calling handle_pending_signals, instead of
immediately when the signal is delivered.  This function is called at
various places, typically when receiving a EINTR from a slow system call
such as read or write.  In the pty exit case, it was called from xwrite,
called from flush, while printing the "exit" message after receiving EOF
when reading from the pty (note that the read did not return EINTR but
zero bytes, indicating EOF).  The SIGHUP handler, phup(), called
rechist, which opened the history file and began writing the merged
history to it.  This process invoked flush recursively to actually write
the data.  In this case, however, the flush noticed it was being called
recursively and decided fail by calling stderror.  For those more
familiar with the code than I am, a stack trace (from the 6.15 code) is
probably worth at least a thousand words (see attached file
tcsh-6.15-rechist-stack-trace.txt).

My conclusion was that the signal was being handled at a bad time.  But
whether to fix flush not to care about the recursive call, or to handle
the signal some other time and when to handle it, was unclear to me.
However, by adding an extra call to handle_pending_signals, just after
process() returns to main(), I was able to avoid the truncated history
after network outages and similar failures.  I verified this fix in
version 6.17.

I wanted to create a test program using the autotest infrastructure, but
I wasn't sure if there was any standard tool that would create a pty.
So as a work-around I implemented the test in three ways, one using
"script", a second using "xterm" and finally with a short C program.
Presumably, one of these methods will work on most systems.  The test
tries all three. I've attached history.at that runs these tests and can
be included in tests/testsuite.at by inserting the line
"m4_include([history.at])" with the other includes.

Ted Anderson

[1] ftp://ftp.astron.com/pub/tcsh/old/
-------------- next part --------------
    #0  xexit (i=1) at sh.c:2274
    #1  0x08052319 in stderror (id=0) at sh.err.c:633
    #2  0x08064360 in flush () at sh.print.c:237
    #3  0x08086aaf in doprnt (addchar=0x80644c0 <xputchar>, 
	sfmt=0xa <Address 0xa out of bounds>, ap=0xbfdf2e58 "") at tc.printf.c:79
    #4  0x08087589 in xprintf (fmt=0x808c9dc "#+%010lu\n") at tc.printf.c:357
    #5  0x0805dc02 in phist (hp=0x80beac8, hflg=64) at sh.hist.c:316
    #6  0x0805dca8 in dohist1 (hp=0x80beac8, np=0xbfdf2f98, hflg=65)
	at sh.hist.c:287
    #7  0x0805dc97 in dohist1 (hp=0x8108c40, np=0xbfdf2f98, hflg=65)
	at sh.hist.c:285
    #8  0x0805dc97 in dohist1 (hp=0x80bed50, np=0xbfdf2f98, hflg=65)
	at sh.hist.c:285
    #9  0x0805dc97 in dohist1 (hp=0x81045f0, np=0xbfdf2f98, hflg=65)
	at sh.hist.c:285
    #10 0x0805dc97 in dohist1 (hp=0x80bebb0, np=0xbfdf2f98, hflg=65)
	at sh.hist.c:285
    #11 0x0805dd81 in dohist (vp=0x80927b0, c=0x0) at sh.hist.c:267
    #12 0x0805df77 in rechist (fname=0x80c0408, ref=1) at sh.hist.c:436
    #13 0x0804bfd9 in record () at sh.c:2362
    #14 0x0804c1fa in phup () at sh.c:1722
    #15 0x08088de2 in handle_pending_signals () at tc.sig.c:69
    #16 0x080628c5 in xwrite (fildes=17, buf=0x80a8480, nbyte=5) at sh.misc.c:663
    #17 0x0806430d in flush () at sh.print.c:254
    #18 0x08086aaf in doprnt (addchar=0x80644c0 <xputchar>, 
	sfmt=0xa <Address 0xa out of bounds>, ap=0xbfdf3144 "\2342??\214")
	at tc.printf.c:79
    #19 0x08087589 in xprintf (fmt=0x808aebd "exit\n") at tc.printf.c:357
    #20 0x0804d68a in main (argc=<value optimized out>, argv=0xbfdf3424)
	at sh.c:1320

From christos at zoulas.com  Sat Oct  3 05:15:41 2009
From: christos at zoulas.com (Christos Zoulas)
Date: Fri, 2 Oct 2009 22:15:41 -0400
Subject: Truncated history file after network crash
In-Reply-To: <20091002212945.qgwkg8gkw84ks80c@my.surfvi.com>
	from Ted Anderson (Oct  2,  9:29pm)
Message-ID: <20091003021542.0A6215654F@rebar.astron.com>

On Oct 2,  9:29pm, ota at surfvi.com (Ted Anderson) wrote:
-- Subject: Truncated history file after network crash

| My conclusion was that the signal was being handled at a bad time.  But
| whether to fix flush not to care about the recursive call, or to handle
| the signal some other time and when to handle it, was unclear to me.
| However, by adding an extra call to handle_pending_signals, just after
| process() returns to main(), I was able to avoid the truncated history
| after network outages and similar failures.  I verified this fix in
| version 6.17.

You mean:

Index: sh.c
===================================================================
RCS file: /p/tcsh/cvsroot/tcsh/sh.c,v
retrieving revision 3.147
diff -u -u -r3.147 sh.c
--- sh.c	18 Sep 2009 18:10:29 -0000	3.147
+++ sh.c	3 Oct 2009 02:14:36 -0000
@@ -2023,6 +2023,7 @@
     cleanup_pop_mark(omark);
     resexit(osetexit);
     exitset--;
+    handle_pending_signals();
 }
 
 /*ARGSUSED*/

 ???

christos


From ota at surfvi.com  Sat Oct  3 05:31:09 2009
From: ota at surfvi.com (Ted Anderson)
Date: Fri,  2 Oct 2009 22:31:09 -0400
Subject: Truncated history file after network crash
In-Reply-To: <20091003021542.0A6215654F@rebar.astron.com>
References: <20091003021542.0A6215654F@rebar.astron.com>
Message-ID: <20091002223109.668soosc4488soko@my.surfvi.com>

Quoting from Christos Zoulas <christos at zoulas.com> at 2 Oct 2009 
22:15:41 -0400:

> On Oct 2,  9:29pm, ota at surfvi.com (Ted Anderson) wrote:
> -- Subject: Truncated history file after network crash
>
> | My conclusion was that the signal was being handled at a bad time.  But
> | whether to fix flush not to care about the recursive call, or to handle
> | the signal some other time and when to handle it, was unclear to me.
> | However, by adding an extra call to handle_pending_signals, just after
> | process() returns to main(), I was able to avoid the truncated history
> | after network outages and similar failures.  I verified this fix in
> | version 6.17.
>
> You mean:

No, I put the call in main():

--- /home/ota/src/tcsh-6.17.00/sh.c.orig	2009-06-25 17:15:37.000000000 -0400
+++ sh.c	2009-09-27 22:57:32.000000000 -0400
@@ -1291,6 +1292,8 @@ main(int argc, char **argv)
      /*
       * Mop-up.
       */
+    /* Take care of these (especially HUP) here instead of inside flush. */
+    handle_pending_signals();
      if (intty) {
  	if (loginsh) {
  	    xprintf("logout\n");

Ted

> Index: sh.c
> ===================================================================
> RCS file: /p/tcsh/cvsroot/tcsh/sh.c,v
> retrieving revision 3.147
> diff -u -u -r3.147 sh.c
> --- sh.c	18 Sep 2009 18:10:29 -0000	3.147
> +++ sh.c	3 Oct 2009 02:14:36 -0000
> @@ -2023,6 +2023,7 @@
>      cleanup_pop_mark(omark);
>      resexit(osetexit);
>      exitset--;
> +    handle_pending_signals();
>  }
>
>  /*ARGSUSED*/
>
>  ???
>
> christos


From christos at zoulas.com  Sat Oct  3 05:42:19 2009
From: christos at zoulas.com (Christos Zoulas)
Date: Fri, 2 Oct 2009 22:42:19 -0400
Subject: Truncated history file after network crash
In-Reply-To: <20091002223109.668soosc4488soko@my.surfvi.com>
	from Ted Anderson (Oct  2, 10:31pm)
Message-ID: <20091003024219.69F145654F@rebar.astron.com>

On Oct 2, 10:31pm, ota at surfvi.com (Ted Anderson) wrote:
-- Subject: Re: Truncated history file after network crash

| Quoting from Christos Zoulas <christos at zoulas.com> at 2 Oct 2009 
| 22:15:41 -0400:
| 
| > On Oct 2,  9:29pm, ota at surfvi.com (Ted Anderson) wrote:
| > -- Subject: Truncated history file after network crash
| >
| > | My conclusion was that the signal was being handled at a bad time.  But
| > | whether to fix flush not to care about the recursive call, or to handle
| > | the signal some other time and when to handle it, was unclear to me.
| > | However, by adding an extra call to handle_pending_signals, just after
| > | process() returns to main(), I was able to avoid the truncated history
| > | after network outages and similar failures.  I verified this fix in
| > | version 6.17.
| >
| > You mean:
| 
| No, I put the call in main():
| 
| --- /home/ota/src/tcsh-6.17.00/sh.c.orig	2009-06-25 17:15:37.000000000 -0400
| +++ sh.c	2009-09-27 22:57:32.000000000 -0400
| @@ -1291,6 +1292,8 @@ main(int argc, char **argv)
|       /*
|        * Mop-up.
|        */
| +    /* Take care of these (especially HUP) here instead of inside flush. */
| +    handle_pending_signals();
|       if (intty) {
|   	if (loginsh) {
|   	    xprintf("logout\n");
| 

Ok, I will commit that then.

christos


From ota at surfvi.com  Sat Oct  3 21:56:38 2009
From: ota at surfvi.com (Ted Anderson)
Date: Sat,  3 Oct 2009 14:56:38 -0400
Subject: Truncated history file after network crash
In-Reply-To: <20091003024219.69F145654F@rebar.astron.com>
References: <20091003024219.69F145654F@rebar.astron.com>
Message-ID: <20091003145638.0g0888888sogkck8@my.surfvi.com>

Quoting Christos Zoulas <christos at zoulas.com>:
> On Oct 2, 10:31pm, ota at surfvi.com (Ted Anderson) wrote:
> -- Subject: Re: Truncated history file after network crash
>
> | Quoting from Christos Zoulas <christos at zoulas.com> at 2 Oct 2009
> | 22:15:41 -0400:
> |
> | > On Oct 2,  9:29pm, ota at surfvi.com (Ted Anderson) wrote:
> | > -- Subject: Truncated history file after network crash
> | >
> | > | My conclusion was that the signal was being handled at a bad time.  But
> | > | whether to fix flush not to care about the recursive call, or to handle
> | > | the signal some other time and when to handle it, was unclear to me.
> | > | However, by adding an extra call to handle_pending_signals, just after
> | > | process() returns to main(), I was able to avoid the truncated history
> | > | after network outages and similar failures.  I verified this fix in
> | > | version 6.17.
> | >
> | > You mean:
> |
> | No, I put the call in main():
> |
> | --- /home/ota/src/tcsh-6.17.00/sh.c.orig	2009-06-25 
> 17:15:37.000000000 -0400
> | +++ sh.c	2009-09-27 22:57:32.000000000 -0400
> | @@ -1291,6 +1292,8 @@ main(int argc, char **argv)
> |       /*
> |        * Mop-up.
> |        */
> | +    /* Take care of these (especially HUP) here instead of inside 
> flush. */
> | +    handle_pending_signals();
> |       if (intty) {
> |   	if (loginsh) {
> |   	    xprintf("logout\n");
> |
>
> Ok, I will commit that then.

It would be good to get a fix in soon.

However, this fix is not perfect.  The same failure would still occur if the
SIGHUP arrived during output instead of while waiting for input.  These
circumstances seem less common, but a better solution would be desirable.
Ideally, someone more familiar with the logic inside flush that 
responds to the
recursive invocation should consider the issue.  If flush can't be safely
changed to avoid exiting sometimes, having signals avoid it might be possible.
Perhaps handle_pending_signals() should check whether flush is running (make
flush's interrupted variable public), and defer running signal handlers 
in that
case.  Or perhaps we shouldn't check for pending signals in xwrite, which is
usually called from flush.

Ted

> christos


From christos at zoulas.com  Sat Oct  3 22:03:38 2009
From: christos at zoulas.com (Christos Zoulas)
Date: Sat, 3 Oct 2009 15:03:38 -0400
Subject: Truncated history file after network crash
In-Reply-To: <20091003145638.0g0888888sogkck8@my.surfvi.com>
	from Ted Anderson (Oct  3,  2:56pm)
Message-ID: <20091003190338.88CD05654E@rebar.astron.com>

On Oct 3,  2:56pm, ota at surfvi.com (Ted Anderson) wrote:
-- Subject: Re: Truncated history file after network crash

| Quoting Christos Zoulas <christos at zoulas.com>:
| > On Oct 2, 10:31pm, ota at surfvi.com (Ted Anderson) wrote:
| > -- Subject: Re: Truncated history file after network crash
| >
| > | Quoting from Christos Zoulas <christos at zoulas.com> at 2 Oct 2009
| > | 22:15:41 -0400:
| > |
| > | > On Oct 2,  9:29pm, ota at surfvi.com (Ted Anderson) wrote:
| > | > -- Subject: Truncated history file after network crash
| > | >
| > | > | My conclusion was that the signal was being handled at a bad time.  But
| > | > | whether to fix flush not to care about the recursive call, or to handle
| > | > | the signal some other time and when to handle it, was unclear to me.
| > | > | However, by adding an extra call to handle_pending_signals, just after
| > | > | process() returns to main(), I was able to avoid the truncated history
| > | > | after network outages and similar failures.  I verified this fix in
| > | > | version 6.17.
| > | >
| > | > You mean:
| > |
| > | No, I put the call in main():
| > |
| > | --- /home/ota/src/tcsh-6.17.00/sh.c.orig	2009-06-25 
| > 17:15:37.000000000 -0400
| > | +++ sh.c	2009-09-27 22:57:32.000000000 -0400
| > | @@ -1291,6 +1292,8 @@ main(int argc, char **argv)
| > |       /*
| > |        * Mop-up.
| > |        */
| > | +    /* Take care of these (especially HUP) here instead of inside 
| > flush. */
| > | +    handle_pending_signals();
| > |       if (intty) {
| > |   	if (loginsh) {
| > |   	    xprintf("logout\n");
| > |
| >
| > Ok, I will commit that then.
| 
| It would be good to get a fix in soon.
| 
| However, this fix is not perfect.  The same failure would still occur if the
| SIGHUP arrived during output instead of while waiting for input.  These
| circumstances seem less common, but a better solution would be desirable.
| Ideally, someone more familiar with the logic inside flush that 
| responds to the
| recursive invocation should consider the issue.  If flush can't be safely
| changed to avoid exiting sometimes, having signals avoid it might be possible.
| Perhaps handle_pending_signals() should check whether flush is running (make
| flush's interrupted variable public), and defer running signal handlers 
| in that
| case.  Or perhaps we shouldn't check for pending signals in xwrite, which is
| usually called from flush.

Until we come up with something better I will leave it at this.

christos


From ota at surfvi.com  Sat Oct  3 23:38:49 2009
From: ota at surfvi.com (Ted Anderson)
Date: Sat,  3 Oct 2009 16:38:49 -0400
Subject: Truncated history file after network crash
In-Reply-To: <20091002212945.qgwkg8gkw84ks80c@my.surfvi.com>
References: <20091002212945.qgwkg8gkw84ks80c@my.surfvi.com>
Message-ID: <20091003163849.xc0wwko0csos48oc@my.surfvi.com>

Quoting Ted Anderson <ota at surfvi.com>:
> I've found an fairly serious bug that can cause the history file to be
...
> I wanted to create a test program using the autotest infrastructure, but
> I wasn't sure if there was any standard tool that would create a pty.
> So as a work-around I implemented the test in three ways, one using
> "script", a second using "xterm" and finally with a short C program.
> Presumably, one of these methods will work on most systems.  The test
> tries all three. I've attached history.at that runs these tests and can
> be included in tests/testsuite.at by inserting the line
> "m4_include([history.at])" with the other includes.

I realized that this history.at test will overwrite the .history file of the
user running it.  Problem is that in order to test normal startup and shutdown
processing I can't specify the -f flag, so the normal .tcshrc script and its
history settings are loaded.  Anyway, this is not very nice, so here is an
updated version that either avoids or restores (in the xterm case) the user's
history file.

Ted


From msz at astrouw.edu.pl  Thu Oct 22 21:14:22 2009
From: msz at astrouw.edu.pl (Michal Szymanski)
Date: Thu, 22 Oct 2009 20:14:22 +0200
Subject: change in variable operations (6.14->6.15)) breaks scripts
Message-ID: <20091022181422.GA11660@astrouw.edu.pl>

Hi,

One of my scripts failed after upgrading the Linux (CentOS 5) system
(which involved going with tcsh from 6.14 to 6.15). Debugging yielded
the following:

set c="a/b/c"
set p=( ${c:as+/+ +} )
echo $#p

--> 3 (6.14)
--> 1 (6.15)

Is it a fix or a bug?

regards, Michal.

-- 
  Michal Szymanski (msz at astrouw dot edu dot pl)
  Warsaw University Observatory, Warszawa, POLAND


From christos at zoulas.com  Fri Oct 23 00:01:13 2009
From: christos at zoulas.com (Christos Zoulas)
Date: Thu, 22 Oct 2009 17:01:13 -0400
Subject: change in variable operations (6.14->6.15)) breaks scripts
In-Reply-To: <20091022181422.GA11660@astrouw.edu.pl>
	from Michal Szymanski (Oct 22,  8:14pm)
Message-ID: <20091022210113.8C5475654E@rebar.astron.com>

On Oct 22,  8:14pm, msz at astrouw.edu.pl (Michal Szymanski) wrote:
-- Subject: change in variable operations (6.14->6.15)) breaks scripts

| Hi,
| 
| One of my scripts failed after upgrading the Linux (CentOS 5) system
| (which involved going with tcsh from 6.14 to 6.15). Debugging yielded
| the following:
| 
| set c="a/b/c"
| set p=( ${c:as+/+ +} )
| echo $#p
| 
| --> 3 (6.14)
| --> 1 (6.15)
| 
| Is it a fix or a bug?

Bug. It is 3 again in 6.16.

christos


From msz at astrouw.edu.pl  Fri Oct 23 01:34:55 2009
From: msz at astrouw.edu.pl (Michal Szymanski)
Date: Fri, 23 Oct 2009 00:34:55 +0200
Subject: change in variable operations (6.14->6.15)) breaks scripts
In-Reply-To: <20091022210113.8C5475654E@rebar.astron.com>
References: <20091022181422.GA11660@astrouw.edu.pl>
	<20091022210113.8C5475654E@rebar.astron.com>
Message-ID: <20091022223455.GA22933@astrouw.edu.pl>

> | One of my scripts failed after upgrading the Linux (CentOS 5) system
> | (which involved going with tcsh from 6.14 to 6.15). Debugging yielded
> | the following:
> | 
> | set c="a/b/c"
> | set p=( ${c:as+/+ +} )
> | echo $#p
> | 
> | --> 3 (6.14)
> | --> 1 (6.15)
> | 
> | Is it a fix or a bug?
> 
> Bug. It is 3 again in 6.16.
> 
> christos

Thanks, Christos. BTW, I found that omitting "a" modifier gives,
also strangely, only one word in both 6.14 and 6.15 versions. Is it also
fixed?
 
set c="a/b/c"
set p=( ${c:s+/+ +} )
echo $#p
--> 1

-- 
  Michal Szymanski (msz at astrouw dot edu dot pl)
  Warsaw University Observatory, Warszawa, POLAND


From christos at zoulas.com  Fri Oct 23 16:50:18 2009
From: christos at zoulas.com (Christos Zoulas)
Date: Fri, 23 Oct 2009 09:50:18 -0400
Subject: change in variable operations (6.14->6.15)) breaks scripts
In-Reply-To: <20091022223455.GA22933@astrouw.edu.pl>
	from Michal Szymanski (Oct 23, 12:34am)
Message-ID: <20091023135018.3C9D85654E@rebar.astron.com>

On Oct 23, 12:34am, msz at astrouw.edu.pl (Michal Szymanski) wrote:
-- Subject: Re: change in variable operations (6.14->6.15)) breaks scripts

| Thanks, Christos. BTW, I found that omitting "a" modifier gives,
| also strangely, only one word in both 6.14 and 6.15 versions. Is it also
| fixed?

Yes, it is also fixed in 6.16.

christos


From ota at surfvi.com  Sun Oct 25 20:57:09 2009
From: ota at surfvi.com (Ted Anderson)
Date: Sun, 25 Oct 2009 14:57:09 -0400
Subject: Large history is very slow when starting or exiting tcsh (Issue #84)
Message-ID: <20091025145709.00hwcwccwc8c0gso@my.surfvi.com>

I have a patch for this problem which I have attached to issue 84[1].  The
changes are concisely described in my check-in notes[2].  Let me know if I
should expand on these notes.  I welcome comments on the code from reviewers.

It represents a fairly significant change to the history mechanism, so I would
like to solicit beta-testers.  Especially, helpful would be folks that use
large histories or have the histdup variable set to "erase" or "all".  I would
be happy to help apply the patch, provide (some) Linux binaries, and respond to
questions.

Thanks in advance,
Ted

[1] http://bugs.gw.com/view.php?id=84
[2] http://bugs.gw.com/file_download.php?file_id=67&type=bug


From christos at zoulas.com  Sun Oct 25 22:55:34 2009
From: christos at zoulas.com (Christos Zoulas)
Date: Sun, 25 Oct 2009 16:55:34 -0400
Subject: Large history is very slow when starting or exiting tcsh (Issue
	#84)
In-Reply-To: <20091025145709.00hwcwccwc8c0gso@my.surfvi.com>
	from Ted Anderson (Oct 25,  2:57pm)
Message-ID: <20091025205534.717FC5654E@rebar.astron.com>

On Oct 25,  2:57pm, ota at surfvi.com (Ted Anderson) wrote:
-- Subject: Large history is very slow when starting or exiting tcsh (Issue #

| I have a patch for this problem which I have attached to issue 84[1].  The
| changes are concisely described in my check-in notes[2].  Let me know if I
| should expand on these notes.  I welcome comments on the code from reviewers.
| 
| It represents a fairly significant change to the history mechanism, so I would
| like to solicit beta-testers.  Especially, helpful would be folks that use
| large histories or have the histdup variable set to "erase" or "all".  I would
| be happy to help apply the patch, provide (some) Linux binaries, and respond to
| questions.
| 
| Thanks in advance,
| Ted
| 
| [1] http://bugs.gw.com/view.php?id=84
| [2] http://bugs.gw.com/file_download.php?file_id=67&type=bug
| 

Thanks, I will try it on mine soon, but I don't logout a lot...

christos


From msz at astrouw.edu.pl  Wed Oct 28 17:28:28 2009
From: msz at astrouw.edu.pl (Michal Szymanski)
Date: Wed, 28 Oct 2009 16:28:28 +0100
Subject: another script-breaking change in tcsh :(
Message-ID: <20091028152828.GA30739@astrouw.edu.pl>

Hi,

Looks like the recent updates of tcsh break all of my scripts :)

This time one of my scripts started to fail on

foreach inc ( $argv[2-] )

saying:    argv: Subscript out of range.
when there was only one argument to the shell (the 'inc-s' are meant to
be optional)

This IMHO is against the manual saying:

> It is not an error for a range to be empty if the second argument is
> omitted or in range.

It was working fine in 6.12, fails in both 6.14 and 6.15.

regards,
Michal

PS. Yes, I was advised many times on this forum not to use tcsh for
scripts, but I am a kind of stubborn idiot :) And I will continue being
it until bash makes an effort to, e.g., extract file's extension by
something simpler than ${file##*.} that I have to google out every time.
Or ${file#*.} - who knows why both do work.

-- 
  Michal Szymanski (msz at astrouw dot edu dot pl)
  Warsaw University Observatory, Warszawa, POLAND


From kim at tcsh.org  Wed Oct 28 19:10:15 2009
From: kim at tcsh.org (Kimmo Suominen)
Date: Wed, 28 Oct 2009 13:10:15 -0400
Subject: another script-breaking change in tcsh :(
In-Reply-To: <20091028152828.GA30739@astrouw.edu.pl>
References: <20091028152828.GA30739@astrouw.edu.pl>
Message-ID: <b32e77100910281010w412245b9hff77f7fecda63b3a@mail.gmail.com>

I think that one was already fixed, too. I seem to recall seeing something
like that on the mailing list before.

It's good that you use tcsh a lot -- more bug detection and fixing that
way... :)

Cheers,
+ Kim


On Wed, Oct 28, 2009 at 11:28, Michal Szymanski <msz at astrouw.edu.pl> wrote:

> Hi,
>
> Looks like the recent updates of tcsh break all of my scripts :)
>
> This time one of my scripts started to fail on
>
> foreach inc ( $argv[2-] )
>
> saying:    argv: Subscript out of range.
> when there was only one argument to the shell (the 'inc-s' are meant to
> be optional)
>
> This IMHO is against the manual saying:
>
> > It is not an error for a range to be empty if the second argument is
> > omitted or in range.
>
> It was working fine in 6.12, fails in both 6.14 and 6.15.
>
> regards,
> Michal
>
> PS. Yes, I was advised many times on this forum not to use tcsh for
> scripts, but I am a kind of stubborn idiot :) And I will continue being
> it until bash makes an effort to, e.g., extract file's extension by
> something simpler than ${file##*.} that I have to google out every time.
> Or ${file#*.} - who knows why both do work.
>
> --
>  Michal Szymanski (msz at astrouw dot edu dot pl)
>  Warsaw University Observatory, Warszawa, POLAND
>
> _______________________________________________
> Tcsh mailing list
> Tcsh at mx.gw.com
> http://mx.gw.com/mailman/listinfo/tcsh
>

From christos at zoulas.com  Wed Oct 28 19:10:55 2009
From: christos at zoulas.com (Christos Zoulas)
Date: Wed, 28 Oct 2009 13:10:55 -0400
Subject: another script-breaking change in tcsh :(
In-Reply-To: <20091028152828.GA30739@astrouw.edu.pl>
	from Michal Szymanski (Oct 28,  4:28pm)
Message-ID: <20091028171055.20DEE5654E@rebar.astron.com>

On Oct 28,  4:28pm, msz at astrouw.edu.pl (Michal Szymanski) wrote:
-- Subject: another script-breaking change in tcsh :(

| It was working fine in 6.12, fails in both 6.14 and 6.15.
 
Yes, and it has been fixed since. The current version is 6.17.
Why are you digging up ancient versions?

christos


From msz at astrouw.edu.pl  Wed Oct 28 20:09:04 2009
From: msz at astrouw.edu.pl (Michal Szymanski)
Date: Wed, 28 Oct 2009 19:09:04 +0100
Subject: another script-breaking change in tcsh :(
In-Reply-To: <20091028171055.20DEE5654E@rebar.astron.com>
References: <20091028152828.GA30739@astrouw.edu.pl>
	<20091028171055.20DEE5654E@rebar.astron.com>
Message-ID: <20091028180904.GA13315@astrouw.edu.pl>

On Wed, Oct 28, 2009 at 01:10:55PM -0400, Christos Zoulas wrote:
> On Oct 28,  4:28pm, msz at astrouw.edu.pl (Michal Szymanski) wrote:
> -- Subject: another script-breaking change in tcsh :(
> 
> | It was working fine in 6.12, fails in both 6.14 and 6.15.
>  
> Yes, and it has been fixed since. The current version is 6.17.
> Why are you digging up ancient versions?

Sorry, I am not digging :) I am administering several dozen PCs in my
institute (as an extra job, I am a scientist/teacher mainly) so I try to
avoid manual tuning all those systems. We use CentOS and Fedora, their
latest versions have tcsh 6.14 (CentOS 5.4) and 6.15 (F11). The distros
are apparently not up to date with tcsh. Which is not that strange,
taking into account that neither of them installs tcsh by default.

Looks like I will have to make an exception in treatment of my favorite
shell :)

regards, Michal.

-- 
  Michal Szymanski (msz at astrouw dot edu dot pl)
  Warsaw University Observatory, Warszawa, POLAND


From christos at zoulas.com  Wed Oct 28 20:34:12 2009
From: christos at zoulas.com (Christos Zoulas)
Date: Wed, 28 Oct 2009 14:34:12 -0400
Subject: another script-breaking change in tcsh :(
In-Reply-To: <20091028180904.GA13315@astrouw.edu.pl>
	from Michal Szymanski (Oct 28,  7:09pm)
Message-ID: <20091028183412.69E285654E@rebar.astron.com>

On Oct 28,  7:09pm, msz at astrouw.edu.pl (Michal Szymanski) wrote:
-- Subject: Re: another script-breaking change in tcsh :(

| On Wed, Oct 28, 2009 at 01:10:55PM -0400, Christos Zoulas wrote:
| > On Oct 28,  4:28pm, msz at astrouw.edu.pl (Michal Szymanski) wrote:
| > -- Subject: another script-breaking change in tcsh :(
| > 
| > | It was working fine in 6.12, fails in both 6.14 and 6.15.
| >  
| > Yes, and it has been fixed since. The current version is 6.17.
| > Why are you digging up ancient versions?
| 
| Sorry, I am not digging :) I am administering several dozen PCs in my
| institute (as an extra job, I am a scientist/teacher mainly) so I try to
| avoid manual tuning all those systems. We use CentOS and Fedora, their
| latest versions have tcsh 6.14 (CentOS 5.4) and 6.15 (F11). The distros
| are apparently not up to date with tcsh. Which is not that strange,
| taking into account that neither of them installs tcsh by default.
| 
| Looks like I will have to make an exception in treatment of my favorite
| shell :)

Ok, I understand... Thanks for the heads-up. If you nag them (the distros)
they will upgrade. It is just that nobody is bothering them.

christos


From douglist at macnauchtan.com  Wed Oct 28 20:52:51 2009
From: douglist at macnauchtan.com (Doug McNutt)
Date: Wed, 28 Oct 2009 12:52:51 -0600
Subject: another script-breaking change in tcsh :(
In-Reply-To: <20091028180904.GA13315@astrouw.edu.pl>
References: <20091028152828.GA30739@astrouw.edu.pl>
	<20091028171055.20DEE5654E@rebar.astron.com>
	<20091028180904.GA13315@astrouw.edu.pl>
Message-ID: <p05100305c70e3e22ddb6@[192.168.1.14]>

At 19:09 +0100 10/28/09, Michal Szymanski wrote:
>On Wed, Oct 28, 2009 at 01:10:55PM -0400, Christos Zoulas wrote:
>> On Oct 28,  4:28pm, msz at astrouw.edu.pl (Michal Szymanski) wrote:
>> -- Subject: another script-breaking change in tcsh :(
>> 
>> | It was working fine in 6.12, fails in both 6.14 and 6.15.
>>  
>> Yes, and it has been fixed since. The current version is 6.17.
>> Why are you digging up ancient versions?
>
>Sorry, I am not digging :) I am administering several dozen PCs in my
>institute (as an extra job, I am a scientist/teacher mainly) so I try to
>avoid manual tuning all those systems. We use CentOS and Fedora, their
>latest versions have tcsh 6.14 (CentOS 5.4) and 6.15 (F11). The distros
>are apparently not up to date with tcsh. Which is not that strange,
>taking into account that neither of them installs tcsh by default.
>
>Looks like I will have to make an exception in treatment of my favorite
>shell :)

I have problems compiling tcsh and gedit under ubuntu Linux 8. . .  Some header files and several libraries seem to be not right and the automated updates by ubuntu don't seem to be doing the right thing with regard to dependencies for compilation of either tool. I haven't tried tcsh recently but my recollection is that ./configure was failing. Some of it, and it might be gedit or tcsh, can be related to my use of 64 bit hardware.

6.14.0 (2005-03-05) is what ubuntu delivers and I'd love to improve that.

Any suggestions?

My guess is that the maintainers at Debian and ubuntu are creating binaries on specially maintained machines that differ from the distributions. Some of it is related to gnome2 and gtk libraries that may need to be older than current distribution.

It doesn't help to declare that  "we support only bash" in the introduction and to have tcsh left out of Linux in a Nutshell ed 6.

I'll go to bash when they get rid of required spaces before [  ] characters. ] is not an external tool anymore, dammit.

-- 
--> So do we celebrate the start of a new decade at the end of this year? Or do the tens start at in January 2011? Was the first year, 0000 ACE, assigned Roman numeral I ?<--


From christos at zoulas.com  Wed Oct 28 21:04:48 2009
From: christos at zoulas.com (Christos Zoulas)
Date: Wed, 28 Oct 2009 15:04:48 -0400
Subject: another script-breaking change in tcsh :(
In-Reply-To: <p05100305c70e3e22ddb6@[192.168.1.14]>
	from Doug McNutt (Oct 28, 12:52pm)
Message-ID: <20091028190448.4C3425654E@rebar.astron.com>

On Oct 28, 12:52pm, douglist at macnauchtan.com (Doug McNutt) wrote:
-- Subject: Re: another script-breaking change in tcsh :(

| I have problems compiling tcsh and gedit under ubuntu Linux 8. . .  Some header files and several libraries seem to be not right and the automated updates by ubuntu don't seem to be doing the right thing with regard to dependencies for compilation of either tool. I haven't tried tcsh recently but my recollection is that ./configure was failing. Some of it, and it might be gedit or tcsh, can be related to my use of 64 bit hardware.

Try ftp://ftp.astron.com/pri/tcsh-6.17.tar.gz. This is the head of my tree
as of now, and it compiles and runs fine on ubuntu-9.

christos


From msz at astrouw.edu.pl  Fri Oct 30 00:37:31 2009
From: msz at astrouw.edu.pl (Michal Szymanski)
Date: Thu, 29 Oct 2009 23:37:31 +0100
Subject: mail check at login?
Message-ID: <20091029223731.GA28377@astrouw.edu.pl>

Hi,

Now that I downloaded and successfully built tcsh 6.17 (thanks,
Christos, for the link), before I distribute it to all my systems, one
more question:

We have a centralized mail server and its /var/mail is NFS-exported to
all machines. Many people here still use old good elm for reading mail
so this is the simplest (while probably not the most modern) setup.

Now in rare occasions when the server is down, this setup makes problems
at login time. It is not that important for the ordinary users (who have
their HOMEs also on that server, so thay cannot login anyway) but if I
want to login as root on a console of any client machine, the shell
stops for quite a while until it timeouts. The only reason I can think
of is that it tries to check the mail. If I use bash for root's shell,
it logs in immediately.

I may be wrong (memory, you know! :) but in the past it used to help to
put a zero-sized .hushlogin file in the root's HOME. Now it does not
help and indeed, I did not find any place in the sources containg string
"hushlogin". 

If I am right in my guess, is it a way to prevent tcsh from checking
mail at login time?

regards, Michal.

-- 
  Michal Szymanski (msz at astrouw dot edu dot pl)
  Warsaw University Observatory, Warszawa, POLAND


From andrew at ugh.net.au  Fri Oct 30 01:02:09 2009
From: andrew at ugh.net.au (Andrew)
Date: Thu, 29 Oct 2009 23:02:09 +0000
Subject: mail check at login?
In-Reply-To: <20091029223731.GA28377@astrouw.edu.pl>
References: <20091029223731.GA28377@astrouw.edu.pl>
Message-ID: <250E627E-495C-4E5C-9CDB-F255DDF6631E@ugh.net.au>


On 29 Oct 2009, at 22:37, Michal Szymanski wrote:

> If I am right in my guess, is it a way to prevent tcsh from checking
> mail at login time?

That is controlled by the $mail variable I believe, but if that was  
the case then the delay must be happening while trying to process  
your .tcshrc etc. If that is also the case you can see what is hanging  
by putting "set verbose" at the very start.

Andrew


From christos at zoulas.com  Fri Oct 30 01:30:03 2009
From: christos at zoulas.com (Christos Zoulas)
Date: Thu, 29 Oct 2009 19:30:03 -0400
Subject: mail check at login?
In-Reply-To: <20091029223731.GA28377@astrouw.edu.pl>
	from Michal Szymanski (Oct 29, 11:37pm)
Message-ID: <20091029233003.3CA3E5654E@rebar.astron.com>

On Oct 29, 11:37pm, msz at astrouw.edu.pl (Michal Szymanski) wrote:
-- Subject: mail check at login?

| Hi,
| 
| Now that I downloaded and successfully built tcsh 6.17 (thanks,
| Christos, for the link), before I distribute it to all my systems, one
| more question:
| 
| We have a centralized mail server and its /var/mail is NFS-exported to
| all machines. Many people here still use old good elm for reading mail
| so this is the simplest (while probably not the most modern) setup.
| 
| Now in rare occasions when the server is down, this setup makes problems
| at login time. It is not that important for the ordinary users (who have
| their HOMEs also on that server, so thay cannot login anyway) but if I
| want to login as root on a console of any client machine, the shell
| stops for quite a while until it timeouts. The only reason I can think
| of is that it tries to check the mail. If I use bash for root's shell,
| it logs in immediately.
| 
| I may be wrong (memory, you know! :) but in the past it used to help to
| put a zero-sized .hushlogin file in the root's HOME. Now it does not
| help and indeed, I did not find any place in the sources containg string
| "hushlogin". 
| 
| If I am right in my guess, is it a way to prevent tcsh from checking
| mail at login time?
| 
| regards, Michal.

unsetenv MAIL
unset mail

should do it. But you can strace the shell and see where it is stuck...

christos