Re: bin/52348: sh (alias.c:271) invokes undefined behaviour

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR bin/52348; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: coypu%sdf.org@localhost
Cc: gnats-bugs%NetBSD.org@localhost
Subject: Re: bin/52348: sh (alias.c:271) invokes undefined behaviour
Date: Thu, 29 Jun 2017 14:04:46 +0700

     Date:        Thu, 29 Jun 2017 06:25:30 +0000
     From:        coypu%sdf.org@localhost
     Message-ID:  <20170629062530.GC22727%SDF.ORG@localhost>
 
   | But instead it gives me in these cases:
   | [1]   Abort trap              AWK=/usr/src/obj...
   | *** Error code 134
   | 
   | and no coredump.
 
 That usually means that for some reason there's no permission to
 write the core file.   Not that it is really likely to have helped much.
 
 More useful info (if you really insist on debugging this this way)
 would be
 
 	if (*p < 0) out2fmt("Weird alias: <<%s>>\n", p);
 
 and then run the shell with stderr directed to a file, so we see
 exactly what bytes are printed, not to a terminal with cut & paste later).
 
 You could probably add, to your $ENV file
 
 	exec 7>&2 2>/tmp/sh-alias-debug
 
 (pick your own file name) right at the top, and then
 
 	exec 2>&7 7>&-
 
 at the end, to allow just the $ENV processing to have stderr redirected.
 
 
 But still, the most useful thing you can so is send me your $ENV (or
 at least any lines in it which define, or use aliases, and any syntax,
 like loops, fuctions, etc) that enclose them.   That is what will
 provide the best info.
 
 kre