Aren
/
NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
NetBSD/bin/sh/expand.c

1970 lines
42 KiB
C
Raw Normal View History

NFC: DEBUG mode only change. Fix botched cleanup of one TRACE().
2017-06-18 10:50:46 +03:00
/* $NetBSD: expand.c,v 1.117 2017/06/18 07:50:46 kre Exp $ */
convert to new RCS id conventions.
1995-03-21 12:01:59 +03:00
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
/*-
sync with 4.4lite
1994-05-11 21:09:42 +04:00
* Copyright (c) 1991, 1993
* The Regents of the University of California. All rights reserved.
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
*
* This code is derived from software contributed to Berkeley by
* Kenneth Almquist.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
Move UCB-licensed code from 4-clause to 3-clause licence. Patches provided by Joel Baker in PR 22249, verified by myself.
2003-08-07 13:05:01 +04:00
* 3. Neither the name of the University nor the names of its contributors
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
Fix compiler warnings.
1997-07-05 01:01:48 +04:00
#include <sys/cdefs.h>
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
#ifndef lint
convert to new RCS id conventions.
1995-03-21 12:01:59 +03:00
#if 0
Fixed new bug the previous fix introduced: false foo=bar echo $? would print 1 Also fixed the long standing bug: false echo `echo $?` would print 0 The exitstatus needs rethinking and rewriting. The trial and error method is not very efficient
1995-05-15 06:47:38 +04:00
static char sccsid[] = "@(#)expand.c 8.5 (Berkeley) 5/15/95";
convert to new RCS id conventions.
1995-03-21 12:01:59 +03:00
#else
NFC: DEBUG mode only change. Fix botched cleanup of one TRACE().
2017-06-18 10:50:46 +03:00
__RCSID("$NetBSD: expand.c,v 1.117 2017/06/18 07:50:46 kre Exp $");
convert to new RCS id conventions.
1995-03-21 12:01:59 +03:00
#endif
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
#endif /* not lint */
Merge in my changes from vangogh, and fix the x=`false`; echo $? == 0 bug.
1995-05-12 01:28:33 +04:00
#include <sys/types.h>
#include <sys/time.h>
#include <sys/stat.h>
#include <errno.h>
#include <dirent.h>
#include <unistd.h>
#include <pwd.h>
include <limits.h> for CHAR_MIN/CHAR_MAX
2012-03-29 00:11:25 +04:00
#include <limits.h>
Merge in my changes from vangogh, and fix the x=`false`; echo $? == 0 bug.
1995-05-12 01:28:33 +04:00
#include <stdlib.h>
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
#include <stdio.h>
Add wctype(3) support to Shell Patterns. Obtained from FreeBSD.
2014-01-20 18:05:51 +04:00
#include <wctype.h>
Convert the pattern matcher from recursive to backtracking (from FreeBSD).
2017-04-26 20:43:33 +03:00
#include <wchar.h>
Merge in my changes from vangogh, and fix the x=`false`; echo $? == 0 bug.
1995-05-12 01:28:33 +04:00
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
/*
* Routines to expand arguments to commands. We have to deal with
* backquotes, shell variables, and file metacharacters.
*/
#include "shell.h"
#include "main.h"
#include "nodes.h"
#include "eval.h"
#include "expand.h"
#include "syntax.h"
Finish support for all required $(( )) (shell arithmetic) operators, closing PR bin/50958 That meant adding the assignment operators ('=', and all of the +=, *= ...) Currently, ++, --, and ',' are not implemented (none of those are required by posix) but support for them (most likely ',' first) might be added later. To do this, I removed the yacc/lex arithmetic parser completely, and replaced it with a hand written recursive descent parser, that I obtained from FreeBSD, who earlier had obtained it from dash (Herbert Xu). While doing the import, I cleaned up the sources (changed some file names to avoid requiring a clean build, or signifigant surgery to the obj directories if "build.sh -u" was to be used - "build.sh -u" should work fine as it is now) removed some dashisms, applied some KNF, ...
2017-03-20 14:26:07 +03:00
#include "arithmetic.h"
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
#include "parser.h"
#include "jobs.h"
#include "options.h"
PR/45069: Henning Petersen: Use prototypes from builtins.h .
2011-06-19 01:18:46 +04:00
#include "builtins.h"
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
#include "var.h"
#include "input.h"
#include "output.h"
#include "memalloc.h"
#include "error.h"
#include "mystring.h"
Merge in my changes from vangogh, and fix the x=`false`; echo $? == 0 bug.
1995-05-12 01:28:33 +04:00
#include "show.h"
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
/*
* Structure specifying which parts of the string should be searched
* for IFS characters.
*/
struct ifsregion {
struct ifsregion *next; /* next region in list */
int begoff; /* offset of start of region */
int endoff; /* offset of end of region */
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
int inquotes; /* search for nul bytes only */
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
};
char *expdest; /* output of current string */
struct nodelist *argbackq; /* list of back quote expressions */
struct ifsregion ifsfirst; /* first struct in list of ifs regions */
struct ifsregion *ifslastp; /* last struct in list */
struct arglist exparg; /* holds expanded arg list */
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
STATIC const char *argstr(const char *, int);
STATIC const char *exptilde(const char *, int);
Fixes from David Laight: - ansification - format of output of jobs command (etc) - job identiers %+, %- etc - $? and $(...) - correct quoting of output of set, export -p and readonly -p - differentiation between nornal and 'posix special' builtins - correct behaviour (posix) for errors on builtins and special builtins - builtin printf and kill - set -o debug (if compiled with DEBUG) - cd src obj (as ksh - too useful to do without) - unset -e name, remove non-readonly variable from export list. (so I could unset -e PS1 before running the test shell...)
2002-11-25 01:35:38 +03:00
STATIC void expbackq(union node *, int, int);
PR bin/52280 removescapes_nl in expari() even when not quoted, CRTNONL's appear regardless of quoting (unlike CTLESC).
2017-06-07 12:31:30 +03:00
STATIC const char *expari(const char *);
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
STATIC int subevalvar(const char *, const char *, int, int, int);
STATIC int subevalvar_trim(const char *, int, int, int, int, int);
STATIC const char *evalvar(const char *, int);
STATIC int varisset(const char *, int);
STATIC void varvalue(const char *, int, int, int);
Fixes from David Laight: - ansification - format of output of jobs command (etc) - job identiers %+, %- etc - $? and $(...) - correct quoting of output of set, export -p and readonly -p - differentiation between nornal and 'posix special' builtins - correct behaviour (posix) for errors on builtins and special builtins - builtin printf and kill - set -o debug (if compiled with DEBUG) - cd src obj (as ksh - too useful to do without) - unset -e name, remove non-readonly variable from export list. (so I could unset -e PS1 before running the test shell...)
2002-11-25 01:35:38 +03:00
STATIC void recordregion(int, int, int);
STATIC void removerecordregions(int);
STATIC void ifsbreakup(char *, struct arglist *);
STATIC void ifsfree(void);
STATIC void expandmeta(struct strlist *, int);
STATIC void expmeta(char *, char *);
STATIC void addfname(char *);
STATIC struct strlist *expsort(struct strlist *);
STATIC struct strlist *msort(struct strlist *, int);
Convert the pattern matcher from recursive to backtracking (from FreeBSD).
2017-04-26 20:43:33 +03:00
STATIC int patmatch(const char *, const char *, int);
Fixes from David Laight: - ansification - format of output of jobs command (etc) - job identiers %+, %- etc - $? and $(...) - correct quoting of output of set, export -p and readonly -p - differentiation between nornal and 'posix special' builtins - correct behaviour (posix) for errors on builtins and special builtins - builtin printf and kill - set -o debug (if compiled with DEBUG) - cd src obj (as ksh - too useful to do without) - unset -e name, remove non-readonly variable from export list. (so I could unset -e PS1 before running the test shell...)
2002-11-25 01:35:38 +03:00
STATIC char *cvtnum(int, char *);
Convert the pattern matcher from recursive to backtracking (from FreeBSD).
2017-04-26 20:43:33 +03:00
static int collate_range_cmp(wchar_t, wchar_t);
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
STATIC void add_args(struct strlist *);
A better LINENO implementation. This version deletes (well, #if 0's out) the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)). (Code to invert the LINENO hack when required, like when de-compiling the execution tree to provide the "jobs" command strings, is still included, that can be deleted when the LINENO hack is completely removed - look for refs to VSLINENO throughout the code. The var funclinno in parser.c can also be removed, it is used only for the LINENO hack.) This version produces accurate results: $((LINENO)) was made as accurate as the LINENO hack made ${LINENO} which is very good. That's why the LINENO hack is not yet completely removed, so it can be easily re-enabled. If you can tell the difference when it is in use, or not in use, then something has broken (or I managed to miss a case somewhere.) The way that LINENO works is documented in its own (new) section in the man page, so nothing more about that, or the new options, etc, here. This version introduces the possibility of having a "reference" function associated with a variable, which gets called whenever the value of the variable is required (that's what implements LINENO). There is just one function pointer however, so any particular variable gets at most one of the set function (as used for PATH, etc) or the reference function. The VFUNCREF bit in the var flags indicates which func the variable in question uses (if any - the func ptr, as before, can be NULL). I would not call the results of this perfect yet, but it is close.
2017-06-07 08:08:32 +03:00
STATIC void rmescapes_nl(char *);
remove redundant declarations and nexted externs.
2001-02-04 22:52:06 +03:00
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
/*
* Expand shell variables and backquotes inside a here document.
*/
void
Fixes from David Laight: - ansification - format of output of jobs command (etc) - job identiers %+, %- etc - $? and $(...) - correct quoting of output of set, export -p and readonly -p - differentiation between nornal and 'posix special' builtins - correct behaviour (posix) for errors on builtins and special builtins - builtin printf and kill - set -o debug (if compiled with DEBUG) - cd src obj (as ksh - too useful to do without) - unset -e name, remove non-readonly variable from export list. (so I could unset -e PS1 before running the test shell...)
2002-11-25 01:35:38 +03:00
expandhere(union node *arg, int fd)
{
PR bin/50993 - this is a significant rewrite of the way that here documents are processed. Now, when first detected, they are simply read (the only change made to the text is to join lines ended with a \ to the subsequent line, otherwise end marker detection does not work correctly (for here docs with an unquoted endmarker only of course.) This patch also moves the "internal subroutine" for looking for the end marker out of readtoken1() (which had to happen as readtoken1 is no longer reading the here doc when it is needed) - that uses code mostly taken from FreeBSD's sh (thanks!) and along the way results in some restrictions on what the end marker can be being removed. We still do not allow all we should. (from kre@)
2016-03-27 17:39:33 +03:00
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
herefd = fd;
NULL does not need a cast
2011-08-31 20:24:54 +04:00
expandarg(arg, NULL, 0);
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
xwrite(fd, stackblock(), expdest - stackblock());
}
Convert the pattern matcher from recursive to backtracking (from FreeBSD).
2017-04-26 20:43:33 +03:00
static int
collate_range_cmp(wchar_t c1, wchar_t c2)
{
wchar_t s1[2], s2[2];
s1[0] = c1;
s1[1] = L'\0';
s2[0] = c2;
s2[1] = L'\0';
return (wcscoll(s1, s2));
}
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
/*
* Perform variable substitution and command substitution on an argument,
sync with 4.4lite
1994-05-11 21:09:42 +04:00
* placing the resulting list of arguments in arglist. If EXP_FULL is true,
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
* perform splitting and file name expansion. When arglist is NULL, perform
* here document expansion.
*/
void
Fixes from David Laight: - ansification - format of output of jobs command (etc) - job identiers %+, %- etc - $? and $(...) - correct quoting of output of set, export -p and readonly -p - differentiation between nornal and 'posix special' builtins - correct behaviour (posix) for errors on builtins and special builtins - builtin printf and kill - set -o debug (if compiled with DEBUG) - cd src obj (as ksh - too useful to do without) - unset -e name, remove non-readonly variable from export list. (so I could unset -e PS1 before running the test shell...)
2002-11-25 01:35:38 +03:00
expandarg(union node *arg, struct arglist *arglist, int flag)
from James Jegers <jimj@miller.cs.uwm.edu>: quiet -Wall, and squelch some of the worst style errors.
1994-12-04 10:11:37 +03:00
{
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
struct strlist *sp;
char *p;
Another arithmetic expansion recordregion() fix, this time calculate the lenght (used to calculate the end) based upon the correct starting point. Thanks to John Klos for finding and reporting this one.
2017-06-05 05:15:55 +03:00
CTRACE(DBG_EXPAND, ("expandarg(fl=%#x)\n", flag));
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
if (fflag) /* no filename expandsion */
flag &= ~EXP_GLOB;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
argbackq = arg->narg.backquote;
STARTSTACKSTR(expdest);
ifsfirst.next = NULL;
ifslastp = NULL;
A better LINENO implementation. This version deletes (well, #if 0's out) the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)). (Code to invert the LINENO hack when required, like when de-compiling the execution tree to provide the "jobs" command strings, is still included, that can be deleted when the LINENO hack is completely removed - look for refs to VSLINENO throughout the code. The var funclinno in parser.c can also be removed, it is used only for the LINENO hack.) This version produces accurate results: $((LINENO)) was made as accurate as the LINENO hack made ${LINENO} which is very good. That's why the LINENO hack is not yet completely removed, so it can be easily re-enabled. If you can tell the difference when it is in use, or not in use, then something has broken (or I managed to miss a case somewhere.) The way that LINENO works is documented in its own (new) section in the man page, so nothing more about that, or the new options, etc, here. This version introduces the possibility of having a "reference" function associated with a variable, which gets called whenever the value of the variable is required (that's what implements LINENO). There is just one function pointer however, so any particular variable gets at most one of the set function (as used for PATH, etc) or the reference function. The VFUNCREF bit in the var flags indicates which func the variable in question uses (if any - the func ptr, as before, can be NULL). I would not call the results of this perfect yet, but it is close.
2017-06-07 08:08:32 +03:00
line_number = arg->narg.lineno;
Set the line number before expanding args, not after. As the line_number would have usually been set earlier, this change is mostly an effective no-op, but it is better this way (just in case) - not observed to have caused any problems.
2017-06-07 11:07:50 +03:00
argstr(arg->narg.text, flag);
sync with 4.4lite
1994-05-11 21:09:42 +04:00
if (arglist == NULL) {
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
STACKSTRNUL(expdest);
Another arithmetic expansion recordregion() fix, this time calculate the lenght (used to calculate the end) based upon the correct starting point. Thanks to John Klos for finding and reporting this one.
2017-06-05 05:15:55 +03:00
CTRACE(DBG_EXPAND, ("expandarg: no arglist, done (%d) \"%s\"\n",
expdest - stackblock(), stackblock()));
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
return; /* here document expanded */
sync with 4.4lite
1994-05-11 21:09:42 +04:00
}
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
STPUTC('\0', expdest);
Another arithmetic expansion recordregion() fix, this time calculate the lenght (used to calculate the end) based upon the correct starting point. Thanks to John Klos for finding and reporting this one.
2017-06-05 05:15:55 +03:00
CTRACE(DBG_EXPAND, ("expandarg: arglist got (%d) \"%s\"\n",
expdest - stackblock() - 1, stackblock()));
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
p = grabstackstr(expdest);
exparg.lastp = &exparg.list;
sync with 4.4lite
1994-05-11 21:09:42 +04:00
/*
* TODO - EXP_REDIR
*/
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
if (flag & EXP_SPLIT) {
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
ifsbreakup(p, &exparg);
*exparg.lastp = NULL;
exparg.lastp = &exparg.list;
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
if (flag & EXP_GLOB)
expandmeta(exparg.list, flag);
else
add_args(exparg.list);
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
} else {
sync with 4.4lite
1994-05-11 21:09:42 +04:00
if (flag & EXP_REDIR) /*XXX - for now, just remove escapes */
rmescapes(p);
remove useless casts
2016-02-27 19:28:50 +03:00
sp = stalloc(sizeof(*sp));
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
sp->text = p;
*exparg.lastp = sp;
exparg.lastp = &sp->next;
}
Fix bug introduced by EXP_RECORD, where in case there was a variable expansion involved in the `for' list, the list was recorded twice, leading to incorrect argument expansion. Introduce ifsfree() function that free's the IFS region list, GC'ing duplicated code.
1998-02-05 11:32:00 +03:00
ifsfree();
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
*exparg.lastp = NULL;
if (exparg.list) {
*arglist->lastp = exparg.list;
arglist->lastp = exparg.lastp;
}
}
/*
Correctly apply IFS to unquoted text in ${x-text}. Fixes PR/26058 and the 'for i in ${x-a b c}; do ...' and ${x-'a b' c}. I can't find a PR for the latter problem. Regression test goind in shortly.
2004-06-27 02:09:49 +04:00
* Perform variable and command substitution.
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
* If EXP_GLOB is set, output CTLESC characters to allow for further processing.
* If EXP_SPLIT is set, remember location of result for later,
Correctly apply IFS to unquoted text in ${x-text}. Fixes PR/26058 and the 'for i in ${x-a b c}; do ...' and ${x-'a b' c}. I can't find a PR for the latter problem. Regression test goind in shortly.
2004-06-27 02:09:49 +04:00
* Otherwise treat $@ like $* since no splitting will be performed.
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
*/
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
STATIC const char *
argstr(const char *p, int flag)
from James Jegers <jimj@miller.cs.uwm.edu>: quiet -Wall, and squelch some of the worst style errors.
1994-12-04 10:11:37 +03:00
{
kill 'register'
1997-01-11 05:04:27 +03:00
char c;
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
int quotes = flag & (EXP_GLOB | EXP_CASE | EXP_REDIR); /* do CTLESC */
sync with 4.4lite
1994-05-11 21:09:42 +04:00
int firsteq = 1;
appease gcc -Wuninitialized
2005-06-01 19:41:19 +04:00
const char *ifs = NULL;
Correctly apply IFS to unquoted text in ${x-text}. Fixes PR/26058 and the 'for i in ${x-a b c}; do ...' and ${x-'a b' c}. I can't find a PR for the latter problem. Regression test goind in shortly.
2004-06-27 02:09:49 +04:00
int ifs_split = EXP_IFS_SPLIT;
if (flag & EXP_IFS_SPLIT)
General KNF and source code cleanups, avoid scattering the magic string " \t\n" all over the place, slightly improved syntax error messages, restructured some of the code for clarity, don't allow IFS to be imported through the environment, and remove the (never) conditionally compiled ATTY option. Apart from one or two syntax error messages, and ignoring IFS if present in the environment, this is intended to have no user visible changes. (from kre@)
2016-03-27 17:34:46 +03:00
ifs = ifsval();
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
DEBUG mode only change. Convert old trace style to new, and add some more. NFC for any non-DEBUG shell.
2017-06-04 00:52:05 +03:00
CTRACE(DBG_EXPAND, ("argstr(\"%s\", %#x) quotes=%#x\n", p,flag,quotes));
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
sync with 4.4lite
1994-05-11 21:09:42 +04:00
if (*p == '~' && (flag & (EXP_TILDE | EXP_VARTILDE)))
p = exptilde(p, flag);
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
for (;;) {
switch (c = *p++) {
case '\0':
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
STACKSTRNUL(expdest);
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
VTRACE(DBG_EXPAND, ("argstr returning at \"\" "
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
"added \"%s\" to expdest\n", stackblock()));
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
return p - 1;
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
case CTLENDVAR: /* end of expanding yyy in ${xxx-yyy} */
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
case CTLENDARI: /* end of a $(( )) string */
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
STACKSTRNUL(expdest);
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
VTRACE(DBG_EXPAND, ("argstr returning at \"%.6s\"..."
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
" after %2.2X; added \"%s\" to expdest\n",
p, (c&0xff), stackblock()));
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
return p;
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
case CTLQUOTEMARK:
/* "$@" syntax adherence hack */
PR bin/50834o: fix expansions of (unquoted) ${unset_var-} and ""$@ (from kre)
2016-03-08 17:09:07 +03:00
if (p[0] == CTLVAR && p[1] & VSQUOTE &&
p[2] == '@' && p[3] == '=')
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
break;
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
if ((flag & EXP_SPLIT) != 0)
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
STPUTC(c, expdest);
Correctly apply IFS to unquoted text in ${x-text}. Fixes PR/26058 and the 'for i in ${x-a b c}; do ...' and ${x-'a b' c}. I can't find a PR for the latter problem. Regression test goind in shortly.
2004-06-27 02:09:49 +04:00
ifs_split = 0;
break;
A better LINENO implementation. This version deletes (well, #if 0's out) the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)). (Code to invert the LINENO hack when required, like when de-compiling the execution tree to provide the "jobs" command strings, is still included, that can be deleted when the LINENO hack is completely removed - look for refs to VSLINENO throughout the code. The var funclinno in parser.c can also be removed, it is used only for the LINENO hack.) This version produces accurate results: $((LINENO)) was made as accurate as the LINENO hack made ${LINENO} which is very good. That's why the LINENO hack is not yet completely removed, so it can be easily re-enabled. If you can tell the difference when it is in use, or not in use, then something has broken (or I managed to miss a case somewhere.) The way that LINENO works is documented in its own (new) section in the man page, so nothing more about that, or the new options, etc, here. This version introduces the possibility of having a "reference" function associated with a variable, which gets called whenever the value of the variable is required (that's what implements LINENO). There is just one function pointer however, so any particular variable gets at most one of the set function (as used for PATH, etc) or the reference function. The VFUNCREF bit in the var flags indicates which func the variable in question uses (if any - the func ptr, as before, can be NULL). I would not call the results of this perfect yet, but it is close.
2017-06-07 08:08:32 +03:00
case CTLNONL:
if (flag & EXP_NL)
STPUTC(c, expdest);
line_number++;
break;
Correctly apply IFS to unquoted text in ${x-text}. Fixes PR/26058 and the 'for i in ${x-a b c}; do ...' and ${x-'a b' c}. I can't find a PR for the latter problem. Regression test goind in shortly.
2004-06-27 02:09:49 +04:00
case CTLQUOTEEND:
ifs_split = EXP_IFS_SPLIT;
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
break;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
case CTLESC:
sync with 4.4lite
1994-05-11 21:09:42 +04:00
if (quotes)
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
STPUTC(c, expdest);
c = *p++;
STPUTC(c, expdest);
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
if (c == '\n') /* should not happen, but ... */
line_number++;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
break;
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
case CTLVAR: {
#ifdef DEBUG
unsigned int pos = expdest - stackblock();
#endif
Correctly apply IFS to unquoted text in ${x-text}. Fixes PR/26058 and the 'for i in ${x-a b c}; do ...' and ${x-'a b' c}. I can't find a PR for the latter problem. Regression test goind in shortly.
2004-06-27 02:09:49 +04:00
p = evalvar(p, (flag & ~EXP_IFS_SPLIT) | (flag & ifs_split));
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
STACKSTRNUL(expdest);
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
VTRACE(DBG_EXPAND, ("argstr evalvar "
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
"added \"%s\" to expdest\n",
stackblock() + pos));
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
break;
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
}
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
case CTLBACKQ:
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
case CTLBACKQ|CTLQUOTE: {
#ifdef DEBUG
unsigned int pos = expdest - stackblock();
#endif
sync with 4.4lite
1994-05-11 21:09:42 +04:00
expbackq(argbackq->n, c & CTLQUOTE, flag);
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
argbackq = argbackq->next;
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
STACKSTRNUL(expdest);
VTRACE(DBG_EXPAND, ("argstr expbackq added \"%s\" "
"to expdest\n", stackblock() + pos));
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
break;
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
}
case CTLARI: {
#ifdef DEBUG
unsigned int pos = expdest - stackblock();
#endif
PR bin/52280 removescapes_nl in expari() even when not quoted, CRTNONL's appear regardless of quoting (unlike CTLESC).
2017-06-07 12:31:30 +03:00
p = expari(p);
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
STACKSTRNUL(expdest);
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
VTRACE(DBG_EXPAND, ("argstr expari "
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
"+ \"%s\" to expdest p=\"%.5s...\"\n",
stackblock() + pos, p));
sync with 4.4lite
1994-05-11 21:09:42 +04:00
break;
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
}
sync with 4.4lite
1994-05-11 21:09:42 +04:00
case ':':
case '=':
/*
* sort of a hack - expand tildes in variable
* assignments (after the first '=' and after ':'s).
*/
STPUTC(c, expdest);
if (flag & EXP_VARTILDE && *p == '~') {
if (c == '=') {
if (firsteq)
firsteq = 0;
else
break;
}
p = exptilde(p, flag);
}
break;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
default:
A better LINENO implementation. This version deletes (well, #if 0's out) the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)). (Code to invert the LINENO hack when required, like when de-compiling the execution tree to provide the "jobs" command strings, is still included, that can be deleted when the LINENO hack is completely removed - look for refs to VSLINENO throughout the code. The var funclinno in parser.c can also be removed, it is used only for the LINENO hack.) This version produces accurate results: $((LINENO)) was made as accurate as the LINENO hack made ${LINENO} which is very good. That's why the LINENO hack is not yet completely removed, so it can be easily re-enabled. If you can tell the difference when it is in use, or not in use, then something has broken (or I managed to miss a case somewhere.) The way that LINENO works is documented in its own (new) section in the man page, so nothing more about that, or the new options, etc, here. This version introduces the possibility of having a "reference" function associated with a variable, which gets called whenever the value of the variable is required (that's what implements LINENO). There is just one function pointer however, so any particular variable gets at most one of the set function (as used for PATH, etc) or the reference function. The VFUNCREF bit in the var flags indicates which func the variable in question uses (if any - the func ptr, as before, can be NULL). I would not call the results of this perfect yet, but it is close.
2017-06-07 08:08:32 +03:00
if (c == '\n')
line_number++;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
STPUTC(c, expdest);
Fix the expansion of "$(foo-$bar}" so that IFS isn't applied when expanding $bar. Noted by Greg Troxel on tech-userlevel running some 'git' tests. Should fix PR bin/47361
2012-12-23 00:15:22 +04:00
if (flag & ifs_split && strchr(ifs, c) != NULL) {
Correctly apply IFS to unquoted text in ${x-text}. Fixes PR/26058 and the 'for i in ${x-a b c}; do ...' and ${x-'a b' c}. I can't find a PR for the latter problem. Regression test goind in shortly.
2004-06-27 02:09:49 +04:00
/* We need to get the output split here... */
recordregion(expdest - stackblock() - 1,
expdest - stackblock(), 0);
}
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
break;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
}
}
}
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
STATIC const char *
exptilde(const char *p, int flag)
from James Jegers <jimj@miller.cs.uwm.edu>: quiet -Wall, and squelch some of the worst style errors.
1994-12-04 10:11:37 +03:00
{
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
char c;
const char *startp = p;
sync with 4.4lite
1994-05-11 21:09:42 +04:00
struct passwd *pw;
const poisoning.
1998-07-26 23:44:12 +04:00
const char *home;
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
int quotes = flag & (EXP_GLOB | EXP_CASE);
char *user;
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
struct stackmark smark;
#ifdef DEBUG
unsigned int offs = expdest - stackblock();
#endif
setstackmark(&smark);
user = stackblock(); /* we will just borrow top of stack */
sync with 4.4lite
1994-05-11 21:09:42 +04:00
PR bin/52272 - fix an off-by one that broke ~ expansions.
2017-06-05 02:40:31 +03:00
while ((c = *++p) != '\0') {
sync with 4.4lite
1994-05-11 21:09:42 +04:00
switch(c) {
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
case CTLESC: /* any of these occurring */
case CTLVAR: /* means ~ expansion */
case CTLBACKQ: /* does not happen at all */
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
case CTLBACKQ | CTLQUOTE:
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
case CTLARI: /* just leave original unchanged */
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
case CTLENDARI:
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
case CTLQUOTEMARK:
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
case CTLENDVAR:
case '\n':
popstackmark(&smark);
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
return (startp);
A better LINENO implementation. This version deletes (well, #if 0's out) the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)). (Code to invert the LINENO hack when required, like when de-compiling the execution tree to provide the "jobs" command strings, is still included, that can be deleted when the LINENO hack is completely removed - look for refs to VSLINENO throughout the code. The var funclinno in parser.c can also be removed, it is used only for the LINENO hack.) This version produces accurate results: $((LINENO)) was made as accurate as the LINENO hack made ${LINENO} which is very good. That's why the LINENO hack is not yet completely removed, so it can be easily re-enabled. If you can tell the difference when it is in use, or not in use, then something has broken (or I managed to miss a case somewhere.) The way that LINENO works is documented in its own (new) section in the man page, so nothing more about that, or the new options, etc, here. This version introduces the possibility of having a "reference" function associated with a variable, which gets called whenever the value of the variable is required (that's what implements LINENO). There is just one function pointer however, so any particular variable gets at most one of the set function (as used for PATH, etc) or the reference function. The VFUNCREF bit in the var flags indicates which func the variable in question uses (if any - the func ptr, as before, can be NULL). I would not call the results of this perfect yet, but it is close.
2017-06-07 08:08:32 +03:00
case CTLNONL:
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
continue;
sync with 4.4lite
1994-05-11 21:09:42 +04:00
case ':':
if (flag & EXP_VARTILDE)
goto done;
break;
case '/':
goto done;
}
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
STPUTC(c, user);
sync with 4.4lite
1994-05-11 21:09:42 +04:00
}
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
done:
STACKSTRNUL(user);
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
user = stackblock(); /* to start of collected username */
DEBUG mode only change. Convert old trace style to new, and add some more. NFC for any non-DEBUG shell.
2017-06-04 00:52:05 +03:00
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
CTRACE(DBG_EXPAND, ("exptilde, found \"~%s\"", user));
if (*user == '\0') {
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
home = lookupvar("HOME");
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
/*
* if HOME is unset, results are unspecified...
* we used to just leave the ~ unchanged, but
* (some) other shells do ... and this seems more useful.
*/
if (home == NULL && (pw = getpwuid(getuid())) != NULL)
home = pw->pw_dir;
} else if ((pw = getpwnam(user)) == NULL) {
/*
* If user does not exist, results are undefined.
* so we can abort() here if we want, but let's not!
*/
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
home = NULL;
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
} else
sync with 4.4lite
1994-05-11 21:09:42 +04:00
home = pw->pw_dir;
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
VTRACE(DBG_EXPAND, (" ->\"%s\"", home ? home : "<<NULL>>"));
popstackmark(&smark); /* now expdest is valid again */
/*
* Posix XCU 2.6.1: The value of $HOME (for ~) or the initial
* working directory from getpwnam() for ~user
* Nothing there about "except if a null string". So do what it wants.
*/
if (home == NULL /* || *home == '\0' */) {
CTRACE(DBG_EXPAND, (": returning unused \"%s\"\n", startp));
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
return startp;
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
} while ((c = *home++) != '\0') {
- change "extern" variables into int's - remove extern'd variables not actually referenced - don't use char as an array index
1998-03-29 08:41:43 +04:00
if (quotes && SQSYNTAX[(int)c] == CCTL)
sync with 4.4lite
1994-05-11 21:09:42 +04:00
STPUTC(CTLESC, expdest);
STPUTC(c, expdest);
}
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
CTRACE(DBG_EXPAND, (": added %d \"%.*s\" returning \"%s\"\n",
expdest - stackblock() - offs, expdest - stackblock() - offs,
stackblock() + offs, p));
DEBUG mode only change. Convert old trace style to new, and add some more. NFC for any non-DEBUG shell.
2017-06-04 00:52:05 +03:00
sync with 4.4lite
1994-05-11 21:09:42 +04:00
return (p);
}
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
STATIC void
Fixes from David Laight: - ansification - format of output of jobs command (etc) - job identiers %+, %- etc - $? and $(...) - correct quoting of output of set, export -p and readonly -p - differentiation between nornal and 'posix special' builtins - correct behaviour (posix) for errors on builtins and special builtins - builtin printf and kill - set -o debug (if compiled with DEBUG) - cd src obj (as ksh - too useful to do without) - unset -e name, remove non-readonly variable from export list. (so I could unset -e PS1 before running the test shell...)
2002-11-25 01:35:38 +03:00
removerecordregions(int endoff)
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
{
Another arithmetic expansion recordregion() fix, this time calculate the lenght (used to calculate the end) based upon the correct starting point. Thanks to John Klos for finding and reporting this one.
2017-06-05 05:15:55 +03:00
VTRACE(DBG_EXPAND, ("removerecordregions(%d):", endoff));
if (ifslastp == NULL) {
VTRACE(DBG_EXPAND, (" none\n", endoff));
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
return;
Another arithmetic expansion recordregion() fix, this time calculate the lenght (used to calculate the end) based upon the correct starting point. Thanks to John Klos for finding and reporting this one.
2017-06-05 05:15:55 +03:00
}
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
if (ifsfirst.endoff > endoff) {
Another arithmetic expansion recordregion() fix, this time calculate the lenght (used to calculate the end) based upon the correct starting point. Thanks to John Klos for finding and reporting this one.
2017-06-05 05:15:55 +03:00
VTRACE(DBG_EXPAND, (" first(%d)", ifsfirst.endoff));
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
while (ifsfirst.next != NULL) {
struct ifsregion *ifsp;
INTOFF;
ifsp = ifsfirst.next->next;
ckfree(ifsfirst.next);
ifsfirst.next = ifsp;
INTON;
}
if (ifsfirst.begoff > endoff)
ifslastp = NULL;
else {
Another arithmetic expansion recordregion() fix, this time calculate the lenght (used to calculate the end) based upon the correct starting point. Thanks to John Klos for finding and reporting this one.
2017-06-05 05:15:55 +03:00
VTRACE(DBG_EXPAND,("->(%d,%d)",ifsfirst.begoff,endoff));
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
ifslastp = &ifsfirst;
ifsfirst.endoff = endoff;
}
Another arithmetic expansion recordregion() fix, this time calculate the lenght (used to calculate the end) based upon the correct starting point. Thanks to John Klos for finding and reporting this one.
2017-06-05 05:15:55 +03:00
VTRACE(DBG_EXPAND, ("\n"));
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
return;
}
PR bin/50834o: fix expansions of (unquoted) ${unset_var-} and ""$@ (from kre)
2016-03-08 17:09:07 +03:00
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
ifslastp = &ifsfirst;
while (ifslastp->next && ifslastp->next->begoff < endoff)
ifslastp=ifslastp->next;
Another arithmetic expansion recordregion() fix, this time calculate the lenght (used to calculate the end) based upon the correct starting point. Thanks to John Klos for finding and reporting this one.
2017-06-05 05:15:55 +03:00
VTRACE(DBG_EXPAND, (" found(%d,%d)", ifslastp->begoff,ifslastp->endoff));
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
while (ifslastp->next != NULL) {
struct ifsregion *ifsp;
INTOFF;
ifsp = ifslastp->next->next;
ckfree(ifslastp->next);
ifslastp->next = ifsp;
INTON;
}
if (ifslastp->endoff > endoff)
ifslastp->endoff = endoff;
Another arithmetic expansion recordregion() fix, this time calculate the lenght (used to calculate the end) based upon the correct starting point. Thanks to John Klos for finding and reporting this one.
2017-06-05 05:15:55 +03:00
VTRACE(DBG_EXPAND, ("->(%d,%d)", ifslastp->begoff,ifslastp->endoff));
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
}
sync with 4.4lite
1994-05-11 21:09:42 +04:00
/*
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
* Expand arithmetic expression.
*
* In this incarnation, we start at the beginning (yes, "Let's start at the
* very beginning. A very good place to start.") and collect the expression
* until the end - which means expanding anything contained within.
*
* Fortunately, argstr() just happens to do that for us...
sync with 4.4lite
1994-05-11 21:09:42 +04:00
*/
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
STATIC const char *
PR bin/52280 removescapes_nl in expari() even when not quoted, CRTNONL's appear regardless of quoting (unlike CTLESC).
2017-06-07 12:31:30 +03:00
expari(const char *p)
from James Jegers <jimj@miller.cs.uwm.edu>: quiet -Wall, and squelch some of the worst style errors.
1994-12-04 10:11:37 +03:00
{
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
char *q, *start;
Make /bin/sh use intmax_t (instead of int) for arithmetic in $((...)).
2007-03-25 10:29:26 +04:00
intmax_t result;
int adjustment;
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
int begoff;
int quoted;
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
struct stackmark smark;
sync with 4.4lite
1994-05-11 21:09:42 +04:00
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
/* ifsfree(); */
- varisset(): In positional arguments, take into account VSNUL so that: set -- ""; echo ${1:-wwww} works. - when expanding arithmetic, discard previous ifs recorded regions, since we are doing our own scanning. x=ab; echo $((${#x}+1)) now works. - in ${var#word} fix two bugs: * if there was an exact match, there was an off-by-one bug in the comparison of the words. x=abcd; echo ${x#abcd} * if there was no match, the stack region was not adjusted and the rest of the word was getting written in the wrong place. x=123; echo ${x#abc}X
1997-01-24 20:26:28 +03:00
Finish support for all required $(( )) (shell arithmetic) operators, closing PR bin/50958 That meant adding the assignment operators ('=', and all of the +=, *= ...) Currently, ++, --, and ',' are not implemented (none of those are required by posix) but support for them (most likely ',' first) might be added later. To do this, I removed the yacc/lex arithmetic parser completely, and replaced it with a hand written recursive descent parser, that I obtained from FreeBSD, who earlier had obtained it from dash (Herbert Xu). While doing the import, I cleaned up the sources (changed some file names to avoid requiring a clean build, or signifigant surgery to the obj directories if "build.sh -u" was to be used - "build.sh -u" should work fine as it is now) removed some dashisms, applied some KNF, ...
2017-03-20 14:26:07 +03:00
/*
* SPACE_NEEDED is enough for all possible digits (rounded up)
* plus possible "-", and the terminating '\0', hence, plus 2
*
* The calculation produces the number of bytes needed to
* represent the biggest possible value, in octal. We only
* generate decimal, which takes (often) less digits (never more)
* so this is safe, if occasionally slightly wasteful.
*/
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
#define SPACE_NEEDED ((int)((sizeof(intmax_t) * CHAR_BIT + 2) / 3 + 2))
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
quoted = *p++ == '"';
begoff = expdest - stackblock();
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
VTRACE(DBG_EXPAND, ("expari%s: \"%s\" begoff %d\n",
quoted ? "(quoted)" : "", p, begoff));
A better LINENO implementation. This version deletes (well, #if 0's out) the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)). (Code to invert the LINENO hack when required, like when de-compiling the execution tree to provide the "jobs" command strings, is still included, that can be deleted when the LINENO hack is completely removed - look for refs to VSLINENO throughout the code. The var funclinno in parser.c can also be removed, it is used only for the LINENO hack.) This version produces accurate results: $((LINENO)) was made as accurate as the LINENO hack made ${LINENO} which is very good. That's why the LINENO hack is not yet completely removed, so it can be easily re-enabled. If you can tell the difference when it is in use, or not in use, then something has broken (or I managed to miss a case somewhere.) The way that LINENO works is documented in its own (new) section in the man page, so nothing more about that, or the new options, etc, here. This version introduces the possibility of having a "reference" function associated with a variable, which gets called whenever the value of the variable is required (that's what implements LINENO). There is just one function pointer however, so any particular variable gets at most one of the set function (as used for PATH, etc) or the reference function. The VFUNCREF bit in the var flags indicates which func the variable in question uses (if any - the func ptr, as before, can be NULL). I would not call the results of this perfect yet, but it is close.
2017-06-07 08:08:32 +03:00
p = argstr(p, EXP_NL); /* expand $(( )) string */
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
STPUTC('\0', expdest);
start = stackblock() + begoff;
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
removerecordregions(begoff); /* nothing there is kept */
rmescapes_nl(start); /* convert CRTNONL back into \n's */
setstackmark(&smark);
q = grabstackstr(expdest); /* keep the expression while eval'ing */
A better LINENO implementation. This version deletes (well, #if 0's out) the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)). (Code to invert the LINENO hack when required, like when de-compiling the execution tree to provide the "jobs" command strings, is still included, that can be deleted when the LINENO hack is completely removed - look for refs to VSLINENO throughout the code. The var funclinno in parser.c can also be removed, it is used only for the LINENO hack.) This version produces accurate results: $((LINENO)) was made as accurate as the LINENO hack made ${LINENO} which is very good. That's why the LINENO hack is not yet completely removed, so it can be easily re-enabled. If you can tell the difference when it is in use, or not in use, then something has broken (or I managed to miss a case somewhere.) The way that LINENO works is documented in its own (new) section in the man page, so nothing more about that, or the new options, etc, here. This version introduces the possibility of having a "reference" function associated with a variable, which gets called whenever the value of the variable is required (that's what implements LINENO). There is just one function pointer however, so any particular variable gets at most one of the set function (as used for PATH, etc) or the reference function. The VFUNCREF bit in the var flags indicates which func the variable in question uses (if any - the func ptr, as before, can be NULL). I would not call the results of this perfect yet, but it is close.
2017-06-07 08:08:32 +03:00
result = arith(start, line_number);
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
popstackmark(&smark); /* return the stack to before grab */
- varisset(): In positional arguments, take into account VSNUL so that: set -- ""; echo ${1:-wwww} works. - when expanding arithmetic, discard previous ifs recorded regions, since we are doing our own scanning. x=ab; echo $((${#x}+1)) now works. - in ${var#word} fix two bugs: * if there was an exact match, there was an off-by-one bug in the comparison of the words. x=abcd; echo ${x#abcd} * if there was no match, the stack region was not adjusted and the rest of the word was getting written in the wrong place. x=123; echo ${x#abc}X
1997-01-24 20:26:28 +03:00
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
start = stackblock() + begoff; /* block may have moved */
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
adjustment = expdest - start;
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
STADJUST(-adjustment, expdest); /* remove the argstr() result */
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
CHECKSTRSPACE(SPACE_NEEDED, expdest); /* nb: stack block might move */
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
fmtstr(expdest, SPACE_NEEDED, "%"PRIdMAX, result);
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
for (q = expdest; *q++ != '\0'; ) /* find end of what we added */
sync with 4.4lite
1994-05-11 21:09:42 +04:00
;
- varisset(): In positional arguments, take into account VSNUL so that: set -- ""; echo ${1:-wwww} works. - when expanding arithmetic, discard previous ifs recorded regions, since we are doing our own scanning. x=ab; echo $((${#x}+1)) now works. - in ${var#word} fix two bugs: * if there was an exact match, there was an off-by-one bug in the comparison of the words. x=abcd; echo ${x#abcd} * if there was no match, the stack region was not adjusted and the rest of the word was getting written in the wrong place. x=123; echo ${x#abc}X
1997-01-24 20:26:28 +03:00
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
if (quoted == 0) /* allow weird splitting */
Another arithmetic expansion recordregion() fix, this time calculate the lenght (used to calculate the end) based upon the correct starting point. Thanks to John Klos for finding and reporting this one.
2017-06-05 05:15:55 +03:00
recordregion(begoff, begoff + q - 1 - expdest, 0);
NFC: Code style only. Rather than being perverse and adding the negative of a negative number, just add a positive number instead... (the previous version came about purely as an accident of the way the relevant piece of code was added and debugged.... that's my story anyway!)
2017-06-03 23:55:53 +03:00
adjustment = q - expdest - 1;
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
STADJUST(adjustment, expdest); /* move expdest to end */
NFC: DEBUG mode only change. Fix botched cleanup of one TRACE().
2017-06-18 10:50:46 +03:00
VTRACE(DBG_EXPAND, ("expari: adding %d \"%s\", returning \"%.5s...\"\n",
adjustment, stackblock() + begoff, p));
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
return p;
sync with 4.4lite
1994-05-11 21:09:42 +04:00
}
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
/*
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
* Expand stuff in backwards quotes (these days, any command substitution).
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
*/
STATIC void
Fixes from David Laight: - ansification - format of output of jobs command (etc) - job identiers %+, %- etc - $? and $(...) - correct quoting of output of set, export -p and readonly -p - differentiation between nornal and 'posix special' builtins - correct behaviour (posix) for errors on builtins and special builtins - builtin printf and kill - set -o debug (if compiled with DEBUG) - cd src obj (as ksh - too useful to do without) - unset -e name, remove non-readonly variable from export list. (so I could unset -e PS1 before running the test shell...)
2002-11-25 01:35:38 +03:00
expbackq(union node *cmd, int quoted, int flag)
from James Jegers <jimj@miller.cs.uwm.edu>: quiet -Wall, and squelch some of the worst style errors.
1994-12-04 10:11:37 +03:00
{
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
struct backcmd in;
int i;
char buf[128];
char *p;
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
char *dest = expdest; /* expdest may be reused by eval, use an alt */
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
struct ifsregion saveifs, *savelastp;
struct nodelist *saveargbackq;
char lastc;
int startloc = dest - stackblock();
char const *syntax = quoted? DQSYNTAX : BASESYNTAX;
int saveherefd;
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
int quotes = flag & (EXP_GLOB | EXP_CASE);
PR/45269: Andreas Gustafsson: Instead of falling off the edge when eating trailing newlines if the block has moved, arrange so that trailing newlines are never placed in the string in the first place, by accumulating them and adding them only after we've encountered a non-newline character. This allows also for more efficient appending since we know how much we need beforehand. From FreeBSD.
2011-08-23 14:04:39 +04:00
int nnl;
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
struct stackmark smark;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
VTRACE(DBG_EXPAND, ("expbackq( ..., q=%d flag=%#x) have %d\n",
quoted, flag, startloc));
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
INTOFF;
saveifs = ifsfirst;
savelastp = ifslastp;
saveargbackq = argbackq;
PR/2808: Fix parsing of $n where n > 9 (from FreeBSD)
1996-10-16 18:38:58 +04:00
saveherefd = herefd;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
herefd = -1;
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
setstackmark(&smark); /* preserve the stack */
p = grabstackstr(dest); /* save what we have there currently */
evalbackcmd(cmd, &in); /* evaluate the $( ) tree (using stack) */
popstackmark(&smark); /* and return stack to when we entered */
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
ifsfirst = saveifs;
ifslastp = savelastp;
argbackq = saveargbackq;
herefd = saveherefd;
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
p = in.buf; /* now extract the results */
nnl = 0; /* dropping trailing \n's */
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
for (;;) {
if (--in.nleft < 0) {
if (in.fd < 0)
break;
Use an explicit body for a "until not EINTR" loop.
2015-06-06 18:22:58 +03:00
while ((i = read(in.fd, buf, sizeof buf)) < 0 && errno == EINTR)
continue;
DEBUG mode only change. Convert old trace style to new, and add some more. NFC for any non-DEBUG shell.
2017-06-04 00:52:05 +03:00
VTRACE(DBG_EXPAND, ("expbackq: read returns %d\n", i));
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
if (i <= 0)
break;
p = buf;
in.nleft = i - 1;
}
lastc = *p++;
if (lastc != '\0') {
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
if (lastc == '\n') /* don't save \n yet */
nnl++; /* it might be trailing */
PR/45269: Andreas Gustafsson: Instead of falling off the edge when eating trailing newlines if the block has moved, arrange so that trailing newlines are never placed in the string in the first place, by accumulating them and adding them only after we've encountered a non-newline character. This allows also for more efficient appending since we know how much we need beforehand. From FreeBSD.
2011-08-23 14:04:39 +04:00
else {
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
/*
* We have something other than \n
*
* Before saving it, we need to insert
* any \n's that we have just skipped.
*/
/* XXX
* this hack is just because our
* CHECKSTRSPACE() is lazy, and only
* ever grows the stack once, even
* if that does not allocate the space
* we requested. ie: safe for small
* requests, but not large ones.
* FIXME someday...
*/
if (nnl < 20) {
CHECKSTRSPACE(nnl + 2, dest);
while (nnl > 0) {
nnl--;
USTPUTC('\n', dest);
}
} else {
/* The slower, safer, way */
while (nnl > 0) {
nnl--;
STPUTC('\n', dest);
}
CHECKSTRSPACE(2, dest);
PR/45269: Andreas Gustafsson: Instead of falling off the edge when eating trailing newlines if the block has moved, arrange so that trailing newlines are never placed in the string in the first place, by accumulating them and adding them only after we've encountered a non-newline character. This allows also for more efficient appending since we know how much we need beforehand. From FreeBSD.
2011-08-23 14:04:39 +04:00
}
if (quotes && syntax[(int)lastc] == CCTL)
USTPUTC(CTLESC, dest);
USTPUTC(lastc, dest);
}
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
}
}
Changed so that backquote expansion eats all trailing newlines, not just the last one. Reported by guido@gvr.win.tue.nl (Guido van Rooij). Repeat By: echo "`cat file-with-many-newlines`"
1995-03-01 02:09:43 +03:00
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
if (in.fd >= 0)
close(in.fd);
if (in.buf)
ckfree(in.buf);
if (in.jp)
Fixes from David Laight: - ansification - format of output of jobs command (etc) - job identiers %+, %- etc - $? and $(...) - correct quoting of output of set, export -p and readonly -p - differentiation between nornal and 'posix special' builtins - correct behaviour (posix) for errors on builtins and special builtins - builtin printf and kill - set -o debug (if compiled with DEBUG) - cd src obj (as ksh - too useful to do without) - unset -e name, remove non-readonly variable from export list. (so I could unset -e PS1 before running the test shell...)
2002-11-25 01:35:38 +03:00
back_exitstatus = waitforjob(in.jp);
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
if (quoted == 0)
recordregion(startloc, dest - stackblock(), 0);
DEBUG mode only change. Convert old trace style to new, and add some more. NFC for any non-DEBUG shell.
2017-06-04 00:52:05 +03:00
CTRACE(DBG_EXPAND, ("evalbackq: size=%d: \"%.*s\"\n",
The field width passed for a %.*s printf format is supposed to be int, not ptrdiff_t; on 64-bit platforms the latter will be too wide. Adjust accordingly.
2008-10-16 21:58:29 +04:00
(int)((dest - stackblock()) - startloc),
(int)((dest - stackblock()) - startloc),
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
stackblock() + startloc));
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
expdest = dest; /* all done, expdest is all ours again */
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
INTON;
}
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
STATIC int
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
subevalvar(const char *p, const char *str, int subtype, int startloc,
int varflags)
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
{
char *startp;
int saveherefd = herefd;
struct nodelist *saveargbackq = argbackq;
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
int amount;
Fix PR/2070: Ksh style variable modifiers were broken in /bin/sh, from enami tsugutomo
1996-02-12 18:11:41 +03:00
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
herefd = -1;
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
VTRACE(DBG_EXPAND, ("subevalvar(%d) \"%.20s\" ${%.*s} sloc=%d vf=%x\n",
subtype, p, p-str, str, startloc, varflags));
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
argstr(p, EXP_TILDE);
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
STACKSTRNUL(expdest);
herefd = saveherefd;
argbackq = saveargbackq;
startp = stackblock() + startloc;
switch (subtype) {
case VSASSIGN:
setvar(str, startp, 0);
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
amount = startp - expdest; /* remove what argstr added */
Fix PR/2070: Ksh style variable modifiers were broken in /bin/sh, from enami tsugutomo
1996-02-12 18:11:41 +03:00
STADJUST(amount, expdest);
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
varflags &= ~VSNUL; /*XXX Huh? What's that achieve? */
return 1; /* go back and eval var again */
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
case VSQUESTION:
if (*p != CTLENDVAR) {
outfmt(&errout, "%s\n", startp);
NULL does not need a cast
2011-08-31 20:24:54 +04:00
error(NULL);
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
}
The field width passed for a %.*s printf format is supposed to be int, not ptrdiff_t; on 64-bit platforms the latter will be too wide. Adjust accordingly.
2008-10-16 21:58:29 +04:00
error("%.*s: parameter %snot set",
(int)(p - str - 1),
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
str, (varflags & VSNUL) ? "null or "
: nullstr);
Be more retentive about use of NOTREACHED and noreturn.
1998-07-28 15:41:40 +04:00
/* NOTREACHED */
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
default:
abort();
}
}
STATIC int
subevalvar_trim(const char *p, int strloc, int subtype, int startloc,
int varflags, int quotes)
{
char *startp;
char *str;
char *loc = NULL;
char *q;
int c = 0;
int saveherefd = herefd;
struct nodelist *saveargbackq = argbackq;
int amount;
herefd = -1;
switch (subtype) {
case VSTRIMLEFT:
case VSTRIMLEFTMAX:
case VSTRIMRIGHT:
case VSTRIMRIGHTMAX:
break;
default:
abort();
break;
}
DEBUG mode only change. Convert old trace style to new, and add some more. NFC for any non-DEBUG shell.
2017-06-04 00:52:05 +03:00
VTRACE(DBG_EXPAND,
("subevalvar_trim(\"%.9s\", STR@%d, SUBT=%d, start@%d, vf=%x, q=%x)\n",
p, strloc, subtype, startloc, varflags, quotes));
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
argstr(p, (varflags & (VSQUOTE|VSPATQ)) == VSQUOTE ? 0 : EXP_CASE);
STACKSTRNUL(expdest);
herefd = saveherefd;
argbackq = saveargbackq;
startp = stackblock() + startloc;
str = stackblock() + strloc;
switch (subtype) {
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
case VSTRIMLEFT:
- varisset(): In positional arguments, take into account VSNUL so that: set -- ""; echo ${1:-wwww} works. - when expanding arithmetic, discard previous ifs recorded regions, since we are doing our own scanning. x=ab; echo $((${#x}+1)) now works. - in ${var#word} fix two bugs: * if there was an exact match, there was an off-by-one bug in the comparison of the words. x=abcd; echo ${x#abcd} * if there was no match, the stack region was not adjusted and the rest of the word was getting written in the wrong place. x=123; echo ${x#abc}X
1997-01-24 20:26:28 +03:00
for (loc = startp; loc < str; loc++) {
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
c = *loc;
*loc = '\0';
PR/50179: Timo Buhrmester: sh(1) variable expansion bug
2015-08-27 10:46:47 +03:00
if (patmatch(str, startp, quotes))
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
goto recordleft;
*loc = c;
PR/50179: Timo Buhrmester: sh(1) variable expansion bug
2015-08-27 10:46:47 +03:00
if (quotes && *loc == CTLESC)
PR/7231: Havard Eidnes: Shell quoting/trimming problem
1999-03-26 18:49:34 +03:00
loc++;
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
}
return 0;
case VSTRIMLEFTMAX:
PR/7231: Havard Eidnes: Shell quoting/trimming problem
1999-03-26 18:49:34 +03:00
for (loc = str - 1; loc >= startp;) {
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
c = *loc;
*loc = '\0';
PR/50179: Timo Buhrmester: sh(1) variable expansion bug
2015-08-27 10:46:47 +03:00
if (patmatch(str, startp, quotes))
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
goto recordleft;
*loc = c;
PR/7231: Havard Eidnes: Shell quoting/trimming problem
1999-03-26 18:49:34 +03:00
loc--;
PR/50179: Timo Buhrmester: sh(1) variable expansion bug
2015-08-27 10:46:47 +03:00
if (quotes && loc > startp &&
PR/7231: Havard Eidnes: Shell quoting/trimming problem
1999-03-26 18:49:34 +03:00
*(loc - 1) == CTLESC) {
for (q = startp; q < loc; q++)
if (*q == CTLESC)
q++;
if (q > loc)
loc--;
}
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
}
return 0;
case VSTRIMRIGHT:
PR/7231: Havard Eidnes: Shell quoting/trimming problem
1999-03-26 18:49:34 +03:00
for (loc = str - 1; loc >= startp;) {
PR/50179: Timo Buhrmester: sh(1) variable expansion bug
2015-08-27 10:46:47 +03:00
if (patmatch(str, loc, quotes))
Fix the VSTRIMRIGHT* bugs... The problem was not the string length computation, but lack of '\0' termination. Factor this segment out as common code too, while I am there.
1998-03-23 21:21:02 +03:00
goto recordright;
PR/7231: Havard Eidnes: Shell quoting/trimming problem
1999-03-26 18:49:34 +03:00
loc--;
PR/50179: Timo Buhrmester: sh(1) variable expansion bug
2015-08-27 10:46:47 +03:00
if (quotes && loc > startp &&
PR/7231: Havard Eidnes: Shell quoting/trimming problem
1999-03-26 18:49:34 +03:00
*(loc - 1) == CTLESC) {
for (q = startp; q < loc; q++)
if (*q == CTLESC)
q++;
if (q > loc)
loc--;
}
}
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
return 0;
case VSTRIMRIGHTMAX:
PR/7231: Havard Eidnes: Shell quoting/trimming problem
1999-03-26 18:49:34 +03:00
for (loc = startp; loc < str - 1; loc++) {
PR/50179: Timo Buhrmester: sh(1) variable expansion bug
2015-08-27 10:46:47 +03:00
if (patmatch(str, loc, quotes))
Fix the VSTRIMRIGHT* bugs... The problem was not the string length computation, but lack of '\0' termination. Factor this segment out as common code too, while I am there.
1998-03-23 21:21:02 +03:00
goto recordright;
PR/50179: Timo Buhrmester: sh(1) variable expansion bug
2015-08-27 10:46:47 +03:00
if (quotes && *loc == CTLESC)
PR/7231: Havard Eidnes: Shell quoting/trimming problem
1999-03-26 18:49:34 +03:00
loc++;
}
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
return 0;
default:
abort();
}
recordleft:
Fix the VSTRIMRIGHT* bugs... The problem was not the string length computation, but lack of '\0' termination. Factor this segment out as common code too, while I am there.
1998-03-23 21:21:02 +03:00
*loc = c;
Fix PR/2070: Ksh style variable modifiers were broken in /bin/sh, from enami tsugutomo
1996-02-12 18:11:41 +03:00
amount = ((str - 1) - (loc - startp)) - expdest;
STADJUST(amount, expdest);
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
while (loc != str - 1)
*startp++ = *loc++;
return 1;
Fix the VSTRIMRIGHT* bugs... The problem was not the string length computation, but lack of '\0' termination. Factor this segment out as common code too, while I am there.
1998-03-23 21:21:02 +03:00
recordright:
amount = loc - expdest;
STADJUST(amount, expdest);
STPUTC('\0', expdest);
STADJUST(-1, expdest);
return 1;
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
}
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
/*
* Expand a variable, and return a pointer to the next character in the
* input string.
*/
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
STATIC const char *
evalvar(const char *p, int flag)
from James Jegers <jimj@miller.cs.uwm.edu>: quiet -Wall, and squelch some of the worst style errors.
1994-12-04 10:11:37 +03:00
{
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
int subtype;
sync with 4.4lite
1994-05-11 21:09:42 +04:00
int varflags;
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
const char *var;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
char *val;
Fix for bin/7502, from Tor Egge / FreeBSD. Their commit message: > During variable expansion, the internal representation of the expression > might be relocated. Handle this case.
1999-04-30 21:54:17 +04:00
int patloc;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
int c;
int set;
int special;
int startloc;
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
int varlen;
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
int apply_ifs;
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
int quotes = flag & (EXP_GLOB | EXP_CASE | EXP_REDIR);
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
PR/22640: Paul Jarc: sh mishandles positional parameters in case. Fixed from FreeBSD PR 56147.
2003-09-17 20:01:19 +04:00
varflags = (unsigned char)*p++;
sync with 4.4lite
1994-05-11 21:09:42 +04:00
subtype = varflags & VSTYPE;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
var = p;
minor optimization in evalvar() change sent in bin/23813 by VaX#n8
2003-12-21 11:32:39 +03:00
special = !is_name(*p);
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
p = strchr(p, '=') + 1;
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
DEBUG mode only change. Convert old trace style to new, and add some more. NFC for any non-DEBUG shell.
2017-06-04 00:52:05 +03:00
CTRACE(DBG_EXPAND,
("evalvar \"%.*s\", flag=%#X quotes=%#X vf=%#X subtype=%X\n",
p - var - 1, var, flag, quotes, varflags, subtype));
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
again: /* jump here after setting a variable with ${var=text} */
add crude $LINENO support for FreeBSD
2013-10-02 23:52:58 +04:00
if (varflags & VSLINENO) {
A better LINENO implementation. This version deletes (well, #if 0's out) the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)). (Code to invert the LINENO hack when required, like when de-compiling the execution tree to provide the "jobs" command strings, is still included, that can be deleted when the LINENO hack is completely removed - look for refs to VSLINENO throughout the code. The var funclinno in parser.c can also be removed, it is used only for the LINENO hack.) This version produces accurate results: $((LINENO)) was made as accurate as the LINENO hack made ${LINENO} which is very good. That's why the LINENO hack is not yet completely removed, so it can be easily re-enabled. If you can tell the difference when it is in use, or not in use, then something has broken (or I managed to miss a case somewhere.) The way that LINENO works is documented in its own (new) section in the man page, so nothing more about that, or the new options, etc, here. This version introduces the possibility of having a "reference" function associated with a variable, which gets called whenever the value of the variable is required (that's what implements LINENO). There is just one function pointer however, so any particular variable gets at most one of the set function (as used for PATH, etc) or the reference function. The VFUNCREF bit in the var flags indicates which func the variable in question uses (if any - the func ptr, as before, can be NULL). I would not call the results of this perfect yet, but it is close.
2017-06-07 08:08:32 +03:00
if (line_num.flags & VUNSET) {
set = 0;
val = NULL;
} else {
set = 1;
special = p - var;
val = NULL;
}
add crude $LINENO support for FreeBSD
2013-10-02 23:52:58 +04:00
} else if (special) {
- varisset(): In positional arguments, take into account VSNUL so that: set -- ""; echo ${1:-wwww} works. - when expanding arithmetic, discard previous ifs recorded regions, since we are doing our own scanning. x=ab; echo $((${#x}+1)) now works. - in ${var#word} fix two bugs: * if there was an exact match, there was an off-by-one bug in the comparison of the words. x=abcd; echo ${x#abcd} * if there was no match, the stack region was not adjusted and the rest of the word was getting written in the wrong place. x=123; echo ${x#abc}X
1997-01-24 20:26:28 +03:00
set = varisset(var, varflags & VSNUL);
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
val = NULL;
} else {
val = lookupvar(var);
Merge in my changes from vangogh, and fix the x=`false`; echo $? == 0 bug.
1995-05-12 01:28:33 +04:00
if (val == NULL || ((varflags & VSNUL) && val[0] == '\0')) {
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
val = NULL;
set = 0;
} else
set = 1;
}
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
varlen = 0;
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
startloc = expdest - stackblock();
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
Fix PR bin/48202 [non-critical/low]: sh +nounset and `for X; do` iteration fails if parameter set empty by applying and testing FreeBSD's patch of Oct 24 2009 for this; see http://svnweb.freebsd.org/base/head/bin/sh/expand.c?r1=198453&r2=198454 Also created an ATF test in tests/bin/sh/t_expand.sh for this error and corrected a space->tabs problem there as well.
2013-10-07 01:05:50 +04:00
if (!set && uflag && *var != '@' && *var != '*') {
Implement unset variable error messages from Ben Harris.
2002-05-15 18:59:21 +04:00
switch (subtype) {
case VSNORMAL:
case VSTRIMLEFT:
case VSTRIMLEFTMAX:
case VSTRIMRIGHT:
case VSTRIMRIGHTMAX:
case VSLENGTH:
The field width passed for a %.*s printf format is supposed to be int, not ptrdiff_t; on 64-bit platforms the latter will be too wide. Adjust accordingly.
2008-10-16 21:58:29 +04:00
error("%.*s: parameter not set",
(int)(p - var - 1), var);
Implement unset variable error messages from Ben Harris.
2002-05-15 18:59:21 +04:00
/* NOTREACHED */
}
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
}
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
if (set && subtype != VSPLUS) {
/* insert the value of the variable */
if (special) {
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
if (varflags & VSLINENO) {
/*
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
* The LINENO hack (expansion part)
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
*/
while (--special > 0) {
/* not needed, it is a number...
if (quotes && syntax[(int)*var] == CCTL)
STPUTC(CTLESC, expdest);
*/
STPUTC(*var++, expdest);
}
} else
varvalue(var, varflags&VSQUOTE, subtype, flag);
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
if (subtype == VSLENGTH) {
PR/3352: From Hiroyuki Ito: ${#1} was not being expanded properly if there was a need to allocated another stack block.
1997-03-18 21:54:40 +03:00
varlen = expdest - stackblock() - startloc;
STADJUST(-varlen, expdest);
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
}
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
} else {
PR/2808: Fix parsing of $n where n > 9 (from FreeBSD)
1996-10-16 18:38:58 +04:00
char const *syntax = (varflags & VSQUOTE) ? DQSYNTAX
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
: BASESYNTAX;
if (subtype == VSLENGTH) {
for (;*val; val++)
varlen++;
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
} else {
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
while (*val) {
- change "extern" variables into int's - remove extern'd variables not actually referenced - don't use char as an array index
1998-03-29 08:41:43 +04:00
if (quotes && syntax[(int)*val] == CCTL)
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
STPUTC(CTLESC, expdest);
STPUTC(*val++, expdest);
}
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
}
}
}
PR/2808: Fix parsing of $n where n > 9 (from FreeBSD)
1996-10-16 18:38:58 +04:00
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
Fix the expansion of "$(foo-$bar}" so that IFS isn't applied when expanding $bar. Noted by Greg Troxel on tech-userlevel running some 'git' tests. Should fix PR bin/47361
2012-12-23 00:15:22 +04:00
if (flag & EXP_IN_QUOTES)
apply_ifs = 0;
else if (varflags & VSQUOTE) {
if (*var == '@' && shellparam.nparam != 1)
apply_ifs = 1;
else {
/*
* Mark so that we don't apply IFS if we recurse through
* here expanding $bar from "${foo-$bar}".
*/
flag |= EXP_IN_QUOTES;
apply_ifs = 0;
}
} else
apply_ifs = 1;
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
switch (subtype) {
case VSLENGTH:
expdest = cvtnum(varlen, expdest);
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
break;
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
case VSNORMAL:
break;
case VSPLUS:
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
set = !set;
/* FALLTHROUGH */
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
case VSMINUS:
Undo previous fix, breaks: #!/bin/sh echo ${1+"$@"} ./sh.new foo.sh a b c a b c b c I'll revisit this when I have some more time.
2004-06-09 16:17:36 +04:00
if (!set) {
Correctly apply IFS to unquoted text in ${x-text}. Fixes PR/26058 and the 'for i in ${x-a b c}; do ...' and ${x-'a b' c}. I can't find a PR for the latter problem. Regression test goind in shortly.
2004-06-27 02:09:49 +04:00
argstr(p, flag | (apply_ifs ? EXP_IFS_SPLIT : 0));
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
/*
* ${x-a b c} doesn't get split, but removing the
s/apparant/apparent/, from Zafer.
2006-11-25 01:54:47 +03:00
* 'apply_ifs = 0' apparently breaks ${1+"$@"}..
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
* ${x-'a b' c} should generate 2 args.
*/
PR bin/50834o: fix expansions of (unquoted) ${unset_var-} and ""$@ (from kre)
2016-03-08 17:09:07 +03:00
if (*p != CTLENDVAR)
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
/* We should have marked stuff already */
PR bin/50834o: fix expansions of (unquoted) ${unset_var-} and ""$@ (from kre)
2016-03-08 17:09:07 +03:00
apply_ifs = 0;
Undo previous fix, breaks: #!/bin/sh echo ${1+"$@"} ./sh.new foo.sh a b c a b c b c I'll revisit this when I have some more time.
2004-06-09 16:17:36 +04:00
}
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
break;
case VSTRIMLEFT:
case VSTRIMLEFTMAX:
case VSTRIMRIGHT:
case VSTRIMRIGHTMAX:
Fix for the "${unset-var#$(cmd1)}$(cmd2)" runs the wrong command bug. ... From FreeBSD
2017-03-12 07:19:29 +03:00
if (!set) {
set = 1; /* allow argbackq to be advanced if needed */
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
break;
Fix for the "${unset-var#$(cmd1)}$(cmd2)" runs the wrong command bug. ... From FreeBSD
2017-03-12 07:19:29 +03:00
}
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
/*
* Terminate the string and start recording the pattern
* right after it
*/
STPUTC('\0', expdest);
Fix for bin/7502, from Tor Egge / FreeBSD. Their commit message: > During variable expansion, the internal representation of the expression > might be relocated. Handle this case.
1999-04-30 21:54:17 +04:00
patloc = expdest - stackblock();
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
if (subevalvar_trim(p, patloc, subtype, startloc, varflags,
quotes) == 0) {
Fix for bin/7502, from Tor Egge / FreeBSD. Their commit message: > During variable expansion, the internal representation of the expression > might be relocated. Handle this case.
1999-04-30 21:54:17 +04:00
int amount = (expdest - stackblock() - patloc) + 1;
- varisset(): In positional arguments, take into account VSNUL so that: set -- ""; echo ${1:-wwww} works. - when expanding arithmetic, discard previous ifs recorded regions, since we are doing our own scanning. x=ab; echo $((${#x}+1)) now works. - in ${var#word} fix two bugs: * if there was an exact match, there was an off-by-one bug in the comparison of the words. x=abcd; echo ${x#abcd} * if there was no match, the stack region was not adjusted and the rest of the word was getting written in the wrong place. x=123; echo ${x#abc}X
1997-01-24 20:26:28 +03:00
STADJUST(-amount, expdest);
}
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
/* Remove any recorded regions beyond start of variable */
removerecordregions(startloc);
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
apply_ifs = 1;
break;
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
case VSASSIGN:
case VSQUESTION:
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
if (set)
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
break;
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
if (subevalvar(p, var, subtype, startloc, varflags)) {
/* if subevalvar() returns, it always returns 1 */
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
varflags &= ~VSNUL;
/*
* Remove any recorded regions beyond
* start of variable
*/
removerecordregions(startloc);
goto again;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
}
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
apply_ifs = 0; /* never executed */
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
break;
default:
abort();
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
}
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
if (apply_ifs)
recordregion(startloc, expdest - stackblock(),
varflags & VSQUOTE);
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
if (subtype != VSNORMAL) { /* skip to end of alternative */
int nesting = 1;
for (;;) {
if ((c = *p++) == CTLESC)
p++;
A better LINENO implementation. This version deletes (well, #if 0's out) the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)). (Code to invert the LINENO hack when required, like when de-compiling the execution tree to provide the "jobs" command strings, is still included, that can be deleted when the LINENO hack is completely removed - look for refs to VSLINENO throughout the code. The var funclinno in parser.c can also be removed, it is used only for the LINENO hack.) This version produces accurate results: $((LINENO)) was made as accurate as the LINENO hack made ${LINENO} which is very good. That's why the LINENO hack is not yet completely removed, so it can be easily re-enabled. If you can tell the difference when it is in use, or not in use, then something has broken (or I managed to miss a case somewhere.) The way that LINENO works is documented in its own (new) section in the man page, so nothing more about that, or the new options, etc, here. This version introduces the possibility of having a "reference" function associated with a variable, which gets called whenever the value of the variable is required (that's what implements LINENO). There is just one function pointer however, so any particular variable gets at most one of the set function (as used for PATH, etc) or the reference function. The VFUNCREF bit in the var flags indicates which func the variable in question uses (if any - the func ptr, as before, can be NULL). I would not call the results of this perfect yet, but it is close.
2017-06-07 08:08:32 +03:00
else if (c == CTLNONL)
;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
else if (c == CTLBACKQ || c == (CTLBACKQ|CTLQUOTE)) {
Last patch was wrong; just save argbackq around the argstr() call.
1993-10-22 16:32:22 +03:00
if (set)
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
argbackq = argbackq->next;
} else if (c == CTLVAR) {
if ((*p++ & VSTYPE) != VSNORMAL)
nesting++;
} else if (c == CTLENDVAR) {
if (--nesting == 0)
break;
}
}
}
return p;
}
/*
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
* Test whether a special parameter is set.
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
*/
STATIC int
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
varisset(const char *name, int nulok)
- varisset(): In positional arguments, take into account VSNUL so that: set -- ""; echo ${1:-wwww} works. - when expanding arithmetic, discard previous ifs recorded regions, since we are doing our own scanning. x=ab; echo $((${#x}+1)) now works. - in ${var#word} fix two bugs: * if there was an exact match, there was an off-by-one bug in the comparison of the words. x=abcd; echo ${x#abcd} * if there was no match, the stack region was not adjusted and the rest of the word was getting written in the wrong place. x=123; echo ${x#abc}X
1997-01-24 20:26:28 +03:00
{
if (*name == '!')
return backgndpid != -1;
else if (*name == '@' || *name == '*') {
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
if (*shellparam.p == NULL)
return 0;
- varisset(): In positional arguments, take into account VSNUL so that: set -- ""; echo ${1:-wwww} works. - when expanding arithmetic, discard previous ifs recorded regions, since we are doing our own scanning. x=ab; echo $((${#x}+1)) now works. - in ${var#word} fix two bugs: * if there was an exact match, there was an off-by-one bug in the comparison of the words. x=abcd; echo ${x#abcd} * if there was no match, the stack region was not adjusted and the rest of the word was getting written in the wrong place. x=123; echo ${x#abc}X
1997-01-24 20:26:28 +03:00
if (nulok) {
varisset fixes: - treat $0 specially since it is not in shellparams - check the number of parameters instead of walking the parameters array to avoid checking against the null terminated element.
1997-03-03 22:26:18 +03:00
char **av;
for (av = shellparam.p; *av; av++)
if (**av != '\0')
- varisset(): In positional arguments, take into account VSNUL so that: set -- ""; echo ${1:-wwww} works. - when expanding arithmetic, discard previous ifs recorded regions, since we are doing our own scanning. x=ab; echo $((${#x}+1)) now works. - in ${var#word} fix two bugs: * if there was an exact match, there was an off-by-one bug in the comparison of the words. x=abcd; echo ${x#abcd} * if there was no match, the stack region was not adjusted and the rest of the word was getting written in the wrong place. x=123; echo ${x#abc}X
1997-01-24 20:26:28 +03:00
return 1;
return 0;
}
PR/2808: Fix parsing of $n where n > 9 (from FreeBSD)
1996-10-16 18:38:58 +04:00
} else if (is_digit(*name)) {
varisset fixes: - treat $0 specially since it is not in shellparams - check the number of parameters instead of walking the parameters array to avoid checking against the null terminated element.
1997-03-03 22:26:18 +03:00
char *ap;
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
long num;
/*
* handle overflow sensibly (the *ap tests should never fail)
*/
errno = 0;
num = strtol(name, &ap, 10);
if (errno != 0 || (*ap != '\0' && *ap != '='))
return 0;
- varisset(): In positional arguments, take into account VSNUL so that: set -- ""; echo ${1:-wwww} works. - when expanding arithmetic, discard previous ifs recorded regions, since we are doing our own scanning. x=ab; echo $((${#x}+1)) now works. - in ${var#word} fix two bugs: * if there was an exact match, there was an off-by-one bug in the comparison of the words. x=abcd; echo ${x#abcd} * if there was no match, the stack region was not adjusted and the rest of the word was getting written in the wrong place. x=123; echo ${x#abc}X
1997-01-24 20:26:28 +03:00
varisset fixes: - treat $0 specially since it is not in shellparams - check the number of parameters instead of walking the parameters array to avoid checking against the null terminated element.
1997-03-03 22:26:18 +03:00
if (num == 0)
ap = arg0;
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
else if (num > shellparam.nparam)
return 0;
varisset fixes: - treat $0 specially since it is not in shellparams - check the number of parameters instead of walking the parameters array to avoid checking against the null terminated element.
1997-03-03 22:26:18 +03:00
else
ap = shellparam.p[num - 1];
- varisset(): In positional arguments, take into account VSNUL so that: set -- ""; echo ${1:-wwww} works. - when expanding arithmetic, discard previous ifs recorded regions, since we are doing our own scanning. x=ab; echo $((${#x}+1)) now works. - in ${var#word} fix two bugs: * if there was an exact match, there was an off-by-one bug in the comparison of the words. x=abcd; echo ${x#abcd} * if there was no match, the stack region was not adjusted and the rest of the word was getting written in the wrong place. x=123; echo ${x#abc}X
1997-01-24 20:26:28 +03:00
varisset fixes: - treat $0 specially since it is not in shellparams - check the number of parameters instead of walking the parameters array to avoid checking against the null terminated element.
1997-03-03 22:26:18 +03:00
if (nulok && (ap == NULL || *ap == '\0'))
- varisset(): In positional arguments, take into account VSNUL so that: set -- ""; echo ${1:-wwww} works. - when expanding arithmetic, discard previous ifs recorded regions, since we are doing our own scanning. x=ab; echo $((${#x}+1)) now works. - in ${var#word} fix two bugs: * if there was an exact match, there was an off-by-one bug in the comparison of the words. x=abcd; echo ${x#abcd} * if there was no match, the stack region was not adjusted and the rest of the word was getting written in the wrong place. x=123; echo ${x#abc}X
1997-01-24 20:26:28 +03:00
return 0;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
}
return 1;
}
/*
* Add the value of a specialized variable to the stack string.
*/
STATIC void
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
varvalue(const char *name, int quoted, int subtype, int flag)
from James Jegers <jimj@miller.cs.uwm.edu>: quiet -Wall, and squelch some of the worst style errors.
1994-12-04 10:11:37 +03:00
{
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
int num;
char *p;
int i;
char sep;
char **ap;
char const *syntax;
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
if (subtype == VSLENGTH) /* no magic required ... */
flag &= ~EXP_FULL;
sync with 4.4lite
1994-05-11 21:09:42 +04:00
#define STRTODEST(p) \
do {\
Many internal memory management type fixes. PR bin/52302 (core dump with interactive shell, here doc and error on same line) is fixed. (An old bug.) echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )" consistently prints 1002 lines (x, 1000 empty ones, then y) as it should (And you don't want to know what it did before, or why.) (Another old one.) (Recently added) Problems with ~ expansion fixed (mem management related). Proper fix for the cwrappers configure problem (which includes the quick fix that was done earlier, but extends upon that to be correct). (This was another newly added problem.) And the really devious (and rare) old bug - if STACKSTRNUL() needs to allocate a new buffer in which to store the \0, calculate the size of the string space remaining correctly, unlike when SPUTC() grows the buffer, there is no actual data being stored in the STACKSTRNUL() case - the string space remaining was calculated as one byte too few. That would be harmless, unless the next buffer also filled, in which case it was assumed that it was really full, not one byte less, meaning one junk char (a nul, or anything) was being copied into the next (even bigger buffer) corrupting the data. Consistent use of stalloc() to allocate a new block of (stack) memory, and grabstackstr() to claim a block of (stack) memory that had already been occupied but not claimed as in use. Since grabstackstr is implemented as just a call to stalloc() this is a no-op change in practice, but makes it much easier to comprehend what is really happening. Previous code sometimes used stalloc() when the use case was really for grabstackstr(). Change grabstackstr() to actually use the arg passed to it, instead of (not much better than) guessing how much space to claim, More care when using unstalloc()/ungrabstackstr() to return space, and in particular when the stack must be returned to its previous state, rather than just returning no-longer needed space, neither of those work. They also don't work properly if there have been (really, even might have been) any stack mem allocations since the last stalloc()/grabstackstr(). (If we know there cannot have been then the alloc/release sequence is kind of pointless.) To work correctly in general we must use setstackmark()/popstackmark() so do that when needed. Have those also save/restore the top of stack string space remaining. [Aside: for those reading this, the "stack" mentioned is not in any way related to the thing used for maintaining the C function call state, ie: the "stack segment" of the program, but the shell's internal memory management strategy.] More comments to better explain what is happening in some cases. Also cleaned up some hopelessly broken DEBUG mode data that were recently added (no effect on anyone but the poor semi-human attempting to make sense of it...). User visible changes: Proper counting of line numbers when a here document is delimited by a multi-line end-delimiter, as in cat << 'REALLY END' here doc line 1 here doc line 2 REALLY END (which is an obscure case, but nothing says should not work.) The \n in the end-delimiter of the here doc (the last one) was not incrementing the line number, which from that point on in the script would be 1 too low (or more, for end-delimiters with more than one \n in them.) With tilde expansion: unset HOME; echo ~ changed to return getpwuid(getuid())->pw_home instead of failing (returning ~) POSIX says this is unspecified, which makes it difficult for a script to compensate for being run without HOME set (as in env -i sh script), so while not able to be used portably, this seems like a useful extension (and is implemented the same way by some other shells). Further, with HOME=; printf %s ~ we now write nothing (which is required by POSIX - which requires ~ to expand to the value of $HOME if it is set) previously if $HOME (in this case) or a user's directory in the passwd file (for ~user) were a null STRING, We failed the ~ expansion and left behind '~' or '~user'.
2017-06-17 10:22:12 +03:00
if (flag & (EXP_GLOB | EXP_CASE) && subtype != VSLENGTH) { \
syntax = quoted? DQSYNTAX : BASESYNTAX; \
while (*p) { \
if (syntax[(int)*p] == CCTL) \
STPUTC(CTLESC, expdest); \
STPUTC(*p++, expdest); \
} \
} else \
while (*p) \
STPUTC(*p++, expdest); \
sync with 4.4lite
1994-05-11 21:09:42 +04:00
} while (0)
PR/2808: Fix parsing of $n where n > 9 (from FreeBSD)
1996-10-16 18:38:58 +04:00
switch (*name) {
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
case '$':
num = rootpid;
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
break;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
case '?':
Fixes from David Laight: - ansification - format of output of jobs command (etc) - job identiers %+, %- etc - $? and $(...) - correct quoting of output of set, export -p and readonly -p - differentiation between nornal and 'posix special' builtins - correct behaviour (posix) for errors on builtins and special builtins - builtin printf and kill - set -o debug (if compiled with DEBUG) - cd src obj (as ksh - too useful to do without) - unset -e name, remove non-readonly variable from export list. (so I could unset -e PS1 before running the test shell...)
2002-11-25 01:35:38 +03:00
num = exitstatus;
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
break;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
case '#':
num = shellparam.nparam;
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
break;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
case '!':
num = backgndpid;
break;
case '-':
Arrange for set -o and $- output to be sorted, rather than more or less random (and becoming worse as more options are added.) Since the data is known at compile time, sort at compile time, rather than at run time.
2017-05-28 03:38:01 +03:00
for (i = 0; i < option_flags; i++) {
if (optlist[optorder[i]].val)
STPUTC(optlist[optorder[i]].letter, expdest);
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
}
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
return;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
case '@':
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
if (flag & EXP_SPLIT && quoted) {
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
for (ap = shellparam.p ; (p = *ap++) != NULL ; ) {
STRTODEST(p);
Rework the code changes from revisions 1.69, 1.70 and 1.74 so that the code behaves correctly. As far as I can tell, "x$@y" now expands correctly, as does IFS=:; set -$IFS. Fixes PR/33472 (again) and PR/33956
2006-08-22 01:30:14 +04:00
if (*ap)
/* A NUL separates args inside "" */
STPUTC('\0', expdest);
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
}
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
return;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
}
PR/2808: Fix parsing of $n where n > 9 (from FreeBSD)
1996-10-16 18:38:58 +04:00
/* fall through */
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
case '*':
General KNF and source code cleanups, avoid scattering the magic string " \t\n" all over the place, slightly improved syntax error messages, restructured some of the code for clarity, don't allow IFS to be imported through the environment, and remove the (never) conditionally compiled ATTY option. Apart from one or two syntax error messages, and ignoring IFS if present in the environment, this is intended to have no user visible changes. (from kre@)
2016-03-27 17:34:46 +03:00
sep = ifsval()[0];
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
for (ap = shellparam.p ; (p = *ap++) != NULL ; ) {
sync with 4.4lite
1994-05-11 21:09:42 +04:00
STRTODEST(p);
PR bin/52090 - fix expansion of unquoted $*
2017-03-20 14:48:01 +03:00
if (!*ap)
break;
if (sep)
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
STPUTC(sep, expdest);
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
else if ((flag & (EXP_SPLIT|EXP_IN_QUOTES)) == EXP_SPLIT
PR bin/52090 - fix expansion of unquoted $*
2017-03-20 14:48:01 +03:00
&& !quoted && **ap != '\0')
STPUTC('\0', expdest);
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
}
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
return;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
default:
PR/2808: Fix parsing of $n where n > 9 (from FreeBSD)
1996-10-16 18:38:58 +04:00
if (is_digit(*name)) {
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
long lnum;
errno = 0;
lnum = strtol(name, &p, 10);
if (errno != 0 || (*p != '\0' && *p != '='))
return;
if (lnum == 0)
p = arg0;
else if (lnum > 0 && lnum <= shellparam.nparam)
p = shellparam.p[lnum - 1];
else
return;
STRTODEST(p);
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
}
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
return;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
}
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
/*
* only the specials with an int value arrive here
*/
expdest = cvtnum(num, expdest);
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
}
/*
Fix doubled 'the' in comment.
2000-03-14 01:46:59 +03:00
* Record the fact that we have to scan this region of the
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
* string for IFS characters.
*/
STATIC void
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
recordregion(int start, int end, int inquotes)
from James Jegers <jimj@miller.cs.uwm.edu>: quiet -Wall, and squelch some of the worst style errors.
1994-12-04 10:11:37 +03:00
{
kill 'register'
1997-01-11 05:04:27 +03:00
struct ifsregion *ifsp;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
Another arithmetic expansion recordregion() fix, this time calculate the lenght (used to calculate the end) based upon the correct starting point. Thanks to John Klos for finding and reporting this one.
2017-06-05 05:15:55 +03:00
VTRACE(DBG_EXPAND, ("recordregion(%d,%d,%d)\n", start, end, inquotes));
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
if (ifslastp == NULL) {
ifsp = &ifsfirst;
} else {
Don't merge ifs regions with different quoting requirements
2005-03-19 18:02:58 +03:00
if (ifslastp->endoff == start
&& ifslastp->inquotes == inquotes) {
Correctly apply IFS to unquoted text in ${x-text}. Fixes PR/26058 and the 'for i in ${x-a b c}; do ...' and ${x-'a b' c}. I can't find a PR for the latter problem. Regression test goind in shortly.
2004-06-27 02:09:49 +04:00
/* extend previous area */
ifslastp->endoff = end;
return;
}
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
ifsp = (struct ifsregion *)ckmalloc(sizeof (struct ifsregion));
ifslastp->next = ifsp;
}
ifslastp = ifsp;
ifslastp->next = NULL;
ifslastp->begoff = start;
ifslastp->endoff = end;
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
ifslastp->inquotes = inquotes;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
}
/*
* Break the argument string into pieces based upon IFS and add the
* strings to the argument list. The regions of the string to be
* searched for IFS characters have been stored by recordregion.
*/
STATIC void
Fixes from David Laight: - ansification - format of output of jobs command (etc) - job identiers %+, %- etc - $? and $(...) - correct quoting of output of set, export -p and readonly -p - differentiation between nornal and 'posix special' builtins - correct behaviour (posix) for errors on builtins and special builtins - builtin printf and kill - set -o debug (if compiled with DEBUG) - cd src obj (as ksh - too useful to do without) - unset -e name, remove non-readonly variable from export list. (so I could unset -e PS1 before running the test shell...)
2002-11-25 01:35:38 +03:00
ifsbreakup(char *string, struct arglist *arglist)
{
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
struct ifsregion *ifsp;
struct strlist *sp;
char *start;
kill 'register'
1997-01-11 05:04:27 +03:00
char *p;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
char *q;
compile with WARNS = 2
1999-07-09 07:05:49 +04:00
const char *ifs;
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
const char *ifsspc;
Rework the code changes from revisions 1.69, 1.70 and 1.74 so that the code behaves correctly. As far as I can tell, "x$@y" now expands correctly, as does IFS=:; set -$IFS. Fixes PR/33472 (again) and PR/33956
2006-08-22 01:30:14 +04:00
int had_param_ch = 0;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
start = string;
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
DEBUG mode only change. Convert old trace style to new, and add some more. NFC for any non-DEBUG shell.
2017-06-04 00:52:05 +03:00
VTRACE(DBG_EXPAND, ("ifsbreakup(\"%s\")", string)); /* misses \0's */
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
if (ifslastp == NULL) {
/* Return entire argument, IFS doesn't apply to any of it */
DEBUG mode only change. Convert old trace style to new, and add some more. NFC for any non-DEBUG shell.
2017-06-04 00:52:05 +03:00
VTRACE(DBG_EXPAND, ("no regions\n", string));
remove useless casts
2016-02-27 19:28:50 +03:00
sp = stalloc(sizeof(*sp));
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
sp->text = start;
*arglist->lastp = sp;
arglist->lastp = &sp->next;
return;
}
General KNF and source code cleanups, avoid scattering the magic string " \t\n" all over the place, slightly improved syntax error messages, restructured some of the code for clarity, don't allow IFS to be imported through the environment, and remove the (never) conditionally compiled ATTY option. Apart from one or two syntax error messages, and ignoring IFS if present in the environment, this is intended to have no user visible changes. (from kre@)
2016-03-27 17:34:46 +03:00
ifs = ifsval();
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
for (ifsp = &ifsfirst; ifsp != NULL; ifsp = ifsp->next) {
p = string + ifsp->begoff;
DEBUG mode only change. Convert old trace style to new, and add some more. NFC for any non-DEBUG shell.
2017-06-04 00:52:05 +03:00
VTRACE(DBG_EXPAND, (" !%.*s!(%d)", ifsp->endoff-ifsp->begoff,
p, ifsp->endoff-ifsp->begoff));
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
while (p < string + ifsp->endoff) {
Rework the code changes from revisions 1.69, 1.70 and 1.74 so that the code behaves correctly. As far as I can tell, "x$@y" now expands correctly, as does IFS=:; set -$IFS. Fixes PR/33472 (again) and PR/33956
2006-08-22 01:30:14 +04:00
had_param_ch = 1;
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
q = p;
A better LINENO implementation. This version deletes (well, #if 0's out) the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)). (Code to invert the LINENO hack when required, like when de-compiling the execution tree to provide the "jobs" command strings, is still included, that can be deleted when the LINENO hack is completely removed - look for refs to VSLINENO throughout the code. The var funclinno in parser.c can also be removed, it is used only for the LINENO hack.) This version produces accurate results: $((LINENO)) was made as accurate as the LINENO hack made ${LINENO} which is very good. That's why the LINENO hack is not yet completely removed, so it can be easily re-enabled. If you can tell the difference when it is in use, or not in use, then something has broken (or I managed to miss a case somewhere.) The way that LINENO works is documented in its own (new) section in the man page, so nothing more about that, or the new options, etc, here. This version introduces the possibility of having a "reference" function associated with a variable, which gets called whenever the value of the variable is required (that's what implements LINENO). There is just one function pointer however, so any particular variable gets at most one of the set function (as used for PATH, etc) or the reference function. The VFUNCREF bit in the var flags indicates which func the variable in question uses (if any - the func ptr, as before, can be NULL). I would not call the results of this perfect yet, but it is close.
2017-06-07 08:08:32 +03:00
if (*p == CTLNONL) {
p++;
continue;
}
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
if (*p == CTLESC)
p++;
Rework the code changes from revisions 1.69, 1.70 and 1.74 so that the code behaves correctly. As far as I can tell, "x$@y" now expands correctly, as does IFS=:; set -$IFS. Fixes PR/33472 (again) and PR/33956
2006-08-22 01:30:14 +04:00
if (ifsp->inquotes) {
/* Only NULs (should be from "$@") end args */
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
if (*p != 0) {
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
p++;
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
continue;
}
Rework the code changes from revisions 1.69, 1.70 and 1.74 so that the code behaves correctly. As far as I can tell, "x$@y" now expands correctly, as does IFS=:; set -$IFS. Fixes PR/33472 (again) and PR/33956
2006-08-22 01:30:14 +04:00
ifsspc = NULL;
DEBUG mode only change. Convert old trace style to new, and add some more. NFC for any non-DEBUG shell.
2017-06-04 00:52:05 +03:00
VTRACE(DBG_EXPAND, (" \\0 nxt:\"%s\" ", p));
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
} else {
if (!strchr(ifs, *p)) {
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
p++;
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
continue;
}
Set the 'not a parameter' flag when we skip initial whitespace. Otherwise: ./sh -c 'x=" "; for a in $x; do echo a${a}a; done' is processed as a single empty parameter (instead of no parameters). Should fix the breakage I introdiced in rev 1.75 and PR/34256 and PR/34254
2006-08-22 22:11:42 +04:00
had_param_ch = 0;
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
ifsspc = strchr(" \t\n", *p);
/* Ignore IFS whitespace at start */
if (q == start && ifsspc != NULL) {
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
p++;
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
start = p;
continue;
}
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
}
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
/* Save this argument... */
*q = '\0';
DEBUG mode only change. Convert old trace style to new, and add some more. NFC for any non-DEBUG shell.
2017-06-04 00:52:05 +03:00
VTRACE(DBG_EXPAND, ("<%s>", start));
remove useless casts
2016-02-27 19:28:50 +03:00
sp = stalloc(sizeof(*sp));
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
sp->text = start;
*arglist->lastp = sp;
arglist->lastp = &sp->next;
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
p++;
Check quoting before merging ifs regions. sh -c 'set -- a; x="b c"; set -- "$@"$x' now correctly gives $1=ab, $2=c
2005-03-19 19:38:27 +03:00
if (ifsspc != NULL) {
/* Ignore further trailing IFS whitespace */
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
for (; p < string + ifsp->endoff; p++) {
q = p;
A better LINENO implementation. This version deletes (well, #if 0's out) the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)). (Code to invert the LINENO hack when required, like when de-compiling the execution tree to provide the "jobs" command strings, is still included, that can be deleted when the LINENO hack is completely removed - look for refs to VSLINENO throughout the code. The var funclinno in parser.c can also be removed, it is used only for the LINENO hack.) This version produces accurate results: $((LINENO)) was made as accurate as the LINENO hack made ${LINENO} which is very good. That's why the LINENO hack is not yet completely removed, so it can be easily re-enabled. If you can tell the difference when it is in use, or not in use, then something has broken (or I managed to miss a case somewhere.) The way that LINENO works is documented in its own (new) section in the man page, so nothing more about that, or the new options, etc, here. This version introduces the possibility of having a "reference" function associated with a variable, which gets called whenever the value of the variable is required (that's what implements LINENO). There is just one function pointer however, so any particular variable gets at most one of the set function (as used for PATH, etc) or the reference function. The VFUNCREF bit in the var flags indicates which func the variable in question uses (if any - the func ptr, as before, can be NULL). I would not call the results of this perfect yet, but it is close.
2017-06-07 08:08:32 +03:00
if (*p == CTLNONL)
continue;
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
if (*p == CTLESC)
p++;
if (strchr(ifs, *p) == NULL) {
p = q;
break;
}
if (strchr(" \t\n", *p) == NULL) {
Check quoting before merging ifs regions. sh -c 'set -- a; x="b c"; set -- "$@"$x' now correctly gives $1=ab, $2=c
2005-03-19 19:38:27 +03:00
p++;
break;
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
}
}
}
start = p;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
}
No functional changes (intended). Rename some variables, add some comments, and restructure a little. In preparation for fixing "set ${x-a b c}" and friends.
2004-06-26 18:09:58 +04:00
}
Check quoting before merging ifs regions. sh -c 'set -- a; x="b c"; set -- "$@"$x' now correctly gives $1=ab, $2=c
2005-03-19 19:38:27 +03:00
/*
* Save anything left as an argument.
* Traditionally we have treated 'IFS=':'; set -- x$IFS' as
* generating 2 arguments, the second of which is empty.
* Some recent clarification of the Posix spec say that it
* should only generate one....
*/
Rework the code changes from revisions 1.69, 1.70 and 1.74 so that the code behaves correctly. As far as I can tell, "x$@y" now expands correctly, as does IFS=:; set -$IFS. Fixes PR/33472 (again) and PR/33956
2006-08-22 01:30:14 +04:00
if (had_param_ch || *start != 0) {
DEBUG mode only change. Convert old trace style to new, and add some more. NFC for any non-DEBUG shell.
2017-06-04 00:52:05 +03:00
VTRACE(DBG_EXPAND, (" T<%s>", start));
remove useless casts
2016-02-27 19:28:50 +03:00
sp = stalloc(sizeof(*sp));
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
sp->text = start;
*arglist->lastp = sp;
arglist->lastp = &sp->next;
}
DEBUG mode only change. Convert old trace style to new, and add some more. NFC for any non-DEBUG shell.
2017-06-04 00:52:05 +03:00
VTRACE(DBG_EXPAND, ("\n"));
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
}
Fix bug introduced by EXP_RECORD, where in case there was a variable expansion involved in the `for' list, the list was recorded twice, leading to incorrect argument expansion. Introduce ifsfree() function that free's the IFS region list, GC'ing duplicated code.
1998-02-05 11:32:00 +03:00
STATIC void
Fixes from David Laight: - ansification - format of output of jobs command (etc) - job identiers %+, %- etc - $? and $(...) - correct quoting of output of set, export -p and readonly -p - differentiation between nornal and 'posix special' builtins - correct behaviour (posix) for errors on builtins and special builtins - builtin printf and kill - set -o debug (if compiled with DEBUG) - cd src obj (as ksh - too useful to do without) - unset -e name, remove non-readonly variable from export list. (so I could unset -e PS1 before running the test shell...)
2002-11-25 01:35:38 +03:00
ifsfree(void)
Fix bug introduced by EXP_RECORD, where in case there was a variable expansion involved in the `for' list, the list was recorded twice, leading to incorrect argument expansion. Introduce ifsfree() function that free's the IFS region list, GC'ing duplicated code.
1998-02-05 11:32:00 +03:00
{
while (ifsfirst.next != NULL) {
struct ifsregion *ifsp;
INTOFF;
ifsp = ifsfirst.next->next;
ckfree(ifsfirst.next);
ifsfirst.next = ifsp;
INTON;
}
ifslastp = NULL;
ifsfirst.next = NULL;
}
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
/*
* Expand shell metacharacters. At this point, the only control characters
* should be escapes. The results are stored in the list exparg.
*/
char *expdir;
STATIC void
Fixes from David Laight: - ansification - format of output of jobs command (etc) - job identiers %+, %- etc - $? and $(...) - correct quoting of output of set, export -p and readonly -p - differentiation between nornal and 'posix special' builtins - correct behaviour (posix) for errors on builtins and special builtins - builtin printf and kill - set -o debug (if compiled with DEBUG) - cd src obj (as ksh - too useful to do without) - unset -e name, remove non-readonly variable from export list. (so I could unset -e PS1 before running the test shell...)
2002-11-25 01:35:38 +03:00
expandmeta(struct strlist *str, int flag)
from James Jegers <jimj@miller.cs.uwm.edu>: quiet -Wall, and squelch some of the worst style errors.
1994-12-04 10:11:37 +03:00
{
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
char *p;
struct strlist **savelastp;
struct strlist *sp;
char c;
sync with 4.4lite
1994-05-11 21:09:42 +04:00
/* TODO - EXP_REDIR */
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
while (str) {
p = str->text;
for (;;) { /* fast check for meta chars */
if ((c = *p++) == '\0')
goto nometa;
if (c == '*' || c == '?' || c == '[' || c == '!')
break;
}
savelastp = exparg.lastp;
INTOFF;
sync with 4.4lite
1994-05-11 21:09:42 +04:00
if (expdir == NULL) {
int i = strlen(str->text);
expdir = ckmalloc(i < 2048 ? 2048 : i); /* XXX */
}
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
expmeta(expdir, str->text);
ckfree(expdir);
expdir = NULL;
INTON;
if (exparg.lastp == savelastp) {
PR/2808: Fix parsing of $n where n > 9 (from FreeBSD)
1996-10-16 18:38:58 +04:00
/*
* no matches
sync with 4.4lite
1994-05-11 21:09:42 +04:00
*/
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
nometa:
sync with 4.4lite
1994-05-11 21:09:42 +04:00
*exparg.lastp = str;
rmescapes(str->text);
exparg.lastp = &str->next;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
} else {
*exparg.lastp = NULL;
*savelastp = sp = expsort(*savelastp);
while (sp->next != NULL)
sp = sp->next;
exparg.lastp = &sp->next;
}
str = str->next;
}
}
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
STATIC void
add_args(struct strlist *str)
{
while (str) {
*exparg.lastp = str;
rmescapes(str->text);
exparg.lastp = &str->next;
str = str->next;
}
}
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
/*
* Do metacharacter (i.e. *, ?, [...]) expansion.
*/
STATIC void
Fixes from David Laight: - ansification - format of output of jobs command (etc) - job identiers %+, %- etc - $? and $(...) - correct quoting of output of set, export -p and readonly -p - differentiation between nornal and 'posix special' builtins - correct behaviour (posix) for errors on builtins and special builtins - builtin printf and kill - set -o debug (if compiled with DEBUG) - cd src obj (as ksh - too useful to do without) - unset -e name, remove non-readonly variable from export list. (so I could unset -e PS1 before running the test shell...)
2002-11-25 01:35:38 +03:00
expmeta(char *enddir, char *name)
{
kill 'register'
1997-01-11 05:04:27 +03:00
char *p;
compile with WARNS = 2
1999-07-09 07:05:49 +04:00
const char *cp;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
char *q;
char *start;
char *endname;
int metaflag;
struct stat statb;
DIR *dirp;
struct dirent *dp;
int atend;
int matchdot;
metaflag = 0;
start = name;
for (p = name ; ; p++) {
if (*p == '*' || *p == '?')
metaflag = 1;
else if (*p == '[') {
q = p + 1;
if (*q == '!')
q++;
for (;;) {
A better LINENO implementation. This version deletes (well, #if 0's out) the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)). (Code to invert the LINENO hack when required, like when de-compiling the execution tree to provide the "jobs" command strings, is still included, that can be deleted when the LINENO hack is completely removed - look for refs to VSLINENO throughout the code. The var funclinno in parser.c can also be removed, it is used only for the LINENO hack.) This version produces accurate results: $((LINENO)) was made as accurate as the LINENO hack made ${LINENO} which is very good. That's why the LINENO hack is not yet completely removed, so it can be easily re-enabled. If you can tell the difference when it is in use, or not in use, then something has broken (or I managed to miss a case somewhere.) The way that LINENO works is documented in its own (new) section in the man page, so nothing more about that, or the new options, etc, here. This version introduces the possibility of having a "reference" function associated with a variable, which gets called whenever the value of the variable is required (that's what implements LINENO). There is just one function pointer however, so any particular variable gets at most one of the set function (as used for PATH, etc) or the reference function. The VFUNCREF bit in the var flags indicates which func the variable in question uses (if any - the func ptr, as before, can be NULL). I would not call the results of this perfect yet, but it is close.
2017-06-07 08:08:32 +03:00
while (*q == CTLQUOTEMARK || *q == CTLNONL)
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
q++;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
if (*q == CTLESC)
q++;
if (*q == '/' || *q == '\0')
break;
if (*++q == ']') {
metaflag = 1;
break;
}
}
} else if (*p == '!' && p[1] == '!' && (p == name || p[-1] == '/')) {
metaflag = 1;
} else if (*p == '\0')
break;
A better LINENO implementation. This version deletes (well, #if 0's out) the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)). (Code to invert the LINENO hack when required, like when de-compiling the execution tree to provide the "jobs" command strings, is still included, that can be deleted when the LINENO hack is completely removed - look for refs to VSLINENO throughout the code. The var funclinno in parser.c can also be removed, it is used only for the LINENO hack.) This version produces accurate results: $((LINENO)) was made as accurate as the LINENO hack made ${LINENO} which is very good. That's why the LINENO hack is not yet completely removed, so it can be easily re-enabled. If you can tell the difference when it is in use, or not in use, then something has broken (or I managed to miss a case somewhere.) The way that LINENO works is documented in its own (new) section in the man page, so nothing more about that, or the new options, etc, here. This version introduces the possibility of having a "reference" function associated with a variable, which gets called whenever the value of the variable is required (that's what implements LINENO). There is just one function pointer however, so any particular variable gets at most one of the set function (as used for PATH, etc) or the reference function. The VFUNCREF bit in the var flags indicates which func the variable in question uses (if any - the func ptr, as before, can be NULL). I would not call the results of this perfect yet, but it is close.
2017-06-07 08:08:32 +03:00
else if (*p == CTLQUOTEMARK || *p == CTLNONL)
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
continue;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
else if (*p == CTLESC)
p++;
if (*p == '/') {
if (metaflag)
break;
start = p + 1;
}
}
if (metaflag == 0) { /* we've reached the end of the file name */
if (enddir != expdir)
metaflag++;
for (p = name ; ; p++) {
A better LINENO implementation. This version deletes (well, #if 0's out) the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)). (Code to invert the LINENO hack when required, like when de-compiling the execution tree to provide the "jobs" command strings, is still included, that can be deleted when the LINENO hack is completely removed - look for refs to VSLINENO throughout the code. The var funclinno in parser.c can also be removed, it is used only for the LINENO hack.) This version produces accurate results: $((LINENO)) was made as accurate as the LINENO hack made ${LINENO} which is very good. That's why the LINENO hack is not yet completely removed, so it can be easily re-enabled. If you can tell the difference when it is in use, or not in use, then something has broken (or I managed to miss a case somewhere.) The way that LINENO works is documented in its own (new) section in the man page, so nothing more about that, or the new options, etc, here. This version introduces the possibility of having a "reference" function associated with a variable, which gets called whenever the value of the variable is required (that's what implements LINENO). There is just one function pointer however, so any particular variable gets at most one of the set function (as used for PATH, etc) or the reference function. The VFUNCREF bit in the var flags indicates which func the variable in question uses (if any - the func ptr, as before, can be NULL). I would not call the results of this perfect yet, but it is close.
2017-06-07 08:08:32 +03:00
if (*p == CTLQUOTEMARK || *p == CTLNONL)
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
continue;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
if (*p == CTLESC)
p++;
*enddir++ = *p;
if (*p == '\0')
break;
}
Globbing should match broken symlinks. stat()->lstat() to fix this.
2001-03-30 21:45:00 +04:00
if (metaflag == 0 || lstat(expdir, &statb) >= 0)
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
addfname(expdir);
return;
}
endname = p;
if (start != name) {
p = name;
while (p < start) {
A better LINENO implementation. This version deletes (well, #if 0's out) the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)). (Code to invert the LINENO hack when required, like when de-compiling the execution tree to provide the "jobs" command strings, is still included, that can be deleted when the LINENO hack is completely removed - look for refs to VSLINENO throughout the code. The var funclinno in parser.c can also be removed, it is used only for the LINENO hack.) This version produces accurate results: $((LINENO)) was made as accurate as the LINENO hack made ${LINENO} which is very good. That's why the LINENO hack is not yet completely removed, so it can be easily re-enabled. If you can tell the difference when it is in use, or not in use, then something has broken (or I managed to miss a case somewhere.) The way that LINENO works is documented in its own (new) section in the man page, so nothing more about that, or the new options, etc, here. This version introduces the possibility of having a "reference" function associated with a variable, which gets called whenever the value of the variable is required (that's what implements LINENO). There is just one function pointer however, so any particular variable gets at most one of the set function (as used for PATH, etc) or the reference function. The VFUNCREF bit in the var flags indicates which func the variable in question uses (if any - the func ptr, as before, can be NULL). I would not call the results of this perfect yet, but it is close.
2017-06-07 08:08:32 +03:00
while (*p == CTLQUOTEMARK || *p == CTLNONL)
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
p++;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
if (*p == CTLESC)
p++;
*enddir++ = *p++;
}
}
if (enddir == expdir) {
compile with WARNS = 2
1999-07-09 07:05:49 +04:00
cp = ".";
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
} else if (enddir == expdir + 1 && *expdir == '/') {
compile with WARNS = 2
1999-07-09 07:05:49 +04:00
cp = "/";
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
} else {
compile with WARNS = 2
1999-07-09 07:05:49 +04:00
cp = expdir;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
enddir[-1] = '\0';
}
compile with WARNS = 2
1999-07-09 07:05:49 +04:00
if ((dirp = opendir(cp)) == NULL)
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
return;
if (enddir != expdir)
enddir[-1] = '/';
if (*endname == 0) {
atend = 1;
} else {
atend = 0;
*endname++ = '\0';
}
matchdot = 0;
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
p = start;
A better LINENO implementation. This version deletes (well, #if 0's out) the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)). (Code to invert the LINENO hack when required, like when de-compiling the execution tree to provide the "jobs" command strings, is still included, that can be deleted when the LINENO hack is completely removed - look for refs to VSLINENO throughout the code. The var funclinno in parser.c can also be removed, it is used only for the LINENO hack.) This version produces accurate results: $((LINENO)) was made as accurate as the LINENO hack made ${LINENO} which is very good. That's why the LINENO hack is not yet completely removed, so it can be easily re-enabled. If you can tell the difference when it is in use, or not in use, then something has broken (or I managed to miss a case somewhere.) The way that LINENO works is documented in its own (new) section in the man page, so nothing more about that, or the new options, etc, here. This version introduces the possibility of having a "reference" function associated with a variable, which gets called whenever the value of the variable is required (that's what implements LINENO). There is just one function pointer however, so any particular variable gets at most one of the set function (as used for PATH, etc) or the reference function. The VFUNCREF bit in the var flags indicates which func the variable in question uses (if any - the func ptr, as before, can be NULL). I would not call the results of this perfect yet, but it is close.
2017-06-07 08:08:32 +03:00
while (*p == CTLQUOTEMARK || *p == CTLNONL)
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
p++;
if (*p == CTLESC)
p++;
if (*p == '.')
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
matchdot++;
while (! int_pending() && (dp = readdir(dirp)) != NULL) {
if (dp->d_name[0] == '.' && ! matchdot)
continue;
PR/7231: Havard Eidnes: Shell quoting/trimming problem
1999-03-26 18:49:34 +03:00
if (patmatch(start, dp->d_name, 0)) {
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
if (atend) {
scopy(dp->d_name, enddir);
addfname(expdir);
} else {
compile with WARNS = 2
1999-07-09 07:05:49 +04:00
for (p = enddir, cp = dp->d_name;
(*p++ = *cp++) != '\0';)
Merge in my changes from vangogh, and fix the x=`false`; echo $? == 0 bug.
1995-05-12 01:28:33 +04:00
continue;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
p[-1] = '/';
expmeta(p, endname);
}
}
}
closedir(dirp);
if (! atend)
endname[-1] = '/';
}
/*
* Add a file name to the list.
*/
STATIC void
Fixes from David Laight: - ansification - format of output of jobs command (etc) - job identiers %+, %- etc - $? and $(...) - correct quoting of output of set, export -p and readonly -p - differentiation between nornal and 'posix special' builtins - correct behaviour (posix) for errors on builtins and special builtins - builtin printf and kill - set -o debug (if compiled with DEBUG) - cd src obj (as ksh - too useful to do without) - unset -e name, remove non-readonly variable from export list. (so I could unset -e PS1 before running the test shell...)
2002-11-25 01:35:38 +03:00
addfname(char *name)
{
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
char *p;
struct strlist *sp;
p = stalloc(strlen(name) + 1);
scopy(name, p);
remove useless casts
2016-02-27 19:28:50 +03:00
sp = stalloc(sizeof(*sp));
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
sp->text = p;
*exparg.lastp = sp;
exparg.lastp = &sp->next;
}
/*
* Sort the results of file name expansion. It calculates the number of
* strings to sort and then calls msort (short for merge sort) to do the
* work.
*/
STATIC struct strlist *
Fixes from David Laight: - ansification - format of output of jobs command (etc) - job identiers %+, %- etc - $? and $(...) - correct quoting of output of set, export -p and readonly -p - differentiation between nornal and 'posix special' builtins - correct behaviour (posix) for errors on builtins and special builtins - builtin printf and kill - set -o debug (if compiled with DEBUG) - cd src obj (as ksh - too useful to do without) - unset -e name, remove non-readonly variable from export list. (so I could unset -e PS1 before running the test shell...)
2002-11-25 01:35:38 +03:00
expsort(struct strlist *str)
{
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
int len;
struct strlist *sp;
len = 0;
for (sp = str ; sp ; sp = sp->next)
len++;
return msort(str, len);
}
STATIC struct strlist *
Fixes from David Laight: - ansification - format of output of jobs command (etc) - job identiers %+, %- etc - $? and $(...) - correct quoting of output of set, export -p and readonly -p - differentiation between nornal and 'posix special' builtins - correct behaviour (posix) for errors on builtins and special builtins - builtin printf and kill - set -o debug (if compiled with DEBUG) - cd src obj (as ksh - too useful to do without) - unset -e name, remove non-readonly variable from export list. (so I could unset -e PS1 before running the test shell...)
2002-11-25 01:35:38 +03:00
msort(struct strlist *list, int len)
from James Jegers <jimj@miller.cs.uwm.edu>: quiet -Wall, and squelch some of the worst style errors.
1994-12-04 10:11:37 +03:00
{
PR/2808: Fix parsing of $n where n > 9 (from FreeBSD)
1996-10-16 18:38:58 +04:00
struct strlist *p, *q = NULL;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
struct strlist **lpp;
int half;
int n;
if (len <= 1)
return list;
PR/2808: Fix parsing of $n where n > 9 (from FreeBSD)
1996-10-16 18:38:58 +04:00
half = len >> 1;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
p = list;
for (n = half ; --n >= 0 ; ) {
q = p;
p = p->next;
}
q->next = NULL; /* terminate first half of list */
q = msort(list, half); /* sort first half of list */
p = msort(p, len - half); /* sort second half */
lpp = &list;
for (;;) {
if (strcmp(p->text, q->text) < 0) {
*lpp = p;
lpp = &p->next;
if ((p = *lpp) == NULL) {
*lpp = q;
break;
}
} else {
*lpp = q;
lpp = &q->next;
if ((q = *lpp) == NULL) {
*lpp = p;
break;
}
}
}
return list;
}
Add wctype(3) support to Shell Patterns. Obtained from FreeBSD.
2014-01-20 18:05:51 +04:00
/*
* See if a character matches a character class, starting at the first colon
* of "[:class:]".
* If a valid character class is recognized, a pointer to the next character
* after the final closing bracket is stored into *end, otherwise a null
* pointer is stored into *end.
*/
static int
Convert the pattern matcher from recursive to backtracking (from FreeBSD).
2017-04-26 20:43:33 +03:00
match_charclass(const char *p, wchar_t chr, const char **end)
Add wctype(3) support to Shell Patterns. Obtained from FreeBSD.
2014-01-20 18:05:51 +04:00
{
char name[20];
char *nameend;
wctype_t cclass;
*end = NULL;
p++;
nameend = strstr(p, ":]");
if (nameend == NULL || (size_t)(nameend - p) >= sizeof(name) ||
nameend == p)
return 0;
memcpy(name, p, nameend - p);
name[nameend - p] = '\0';
*end = nameend + 2;
cclass = wctype(name);
/* An unknown class matches nothing but is valid nevertheless. */
if (cclass == 0)
return 0;
return iswctype(chr, cclass);
}
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
/*
* Returns true if the pattern matches the string.
*/
STATIC int
Convert the pattern matcher from recursive to backtracking (from FreeBSD).
2017-04-26 20:43:33 +03:00
patmatch(const char *pattern, const char *string, int squoted)
Fixes from David Laight: - ansification - format of output of jobs command (etc) - job identiers %+, %- etc - $? and $(...) - correct quoting of output of set, export -p and readonly -p - differentiation between nornal and 'posix special' builtins - correct behaviour (posix) for errors on builtins and special builtins - builtin printf and kill - set -o debug (if compiled with DEBUG) - cd src obj (as ksh - too useful to do without) - unset -e name, remove non-readonly variable from export list. (so I could unset -e PS1 before running the test shell...)
2002-11-25 01:35:38 +03:00
{
Convert the pattern matcher from recursive to backtracking (from FreeBSD).
2017-04-26 20:43:33 +03:00
const char *p, *q, *end;
const char *bt_p, *bt_q;
kill 'register'
1997-01-11 05:04:27 +03:00
char c;
Convert the pattern matcher from recursive to backtracking (from FreeBSD).
2017-04-26 20:43:33 +03:00
wchar_t wc, wc2;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
p = pattern;
q = string;
Convert the pattern matcher from recursive to backtracking (from FreeBSD).
2017-04-26 20:43:33 +03:00
bt_p = NULL;
bt_q = NULL;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
for (;;) {
switch (c = *p++) {
case '\0':
Convert the pattern matcher from recursive to backtracking (from FreeBSD).
2017-04-26 20:43:33 +03:00
if (*q != '\0')
goto backtrack;
return 1;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
case CTLESC:
PR/7231: Havard Eidnes: Shell quoting/trimming problem
1999-03-26 18:49:34 +03:00
if (squoted && *q == CTLESC)
q++;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
if (*q++ != *p++)
Convert the pattern matcher from recursive to backtracking (from FreeBSD).
2017-04-26 20:43:33 +03:00
goto backtrack;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
break;
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
case CTLQUOTEMARK:
A better LINENO implementation. This version deletes (well, #if 0's out) the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)). (Code to invert the LINENO hack when required, like when de-compiling the execution tree to provide the "jobs" command strings, is still included, that can be deleted when the LINENO hack is completely removed - look for refs to VSLINENO throughout the code. The var funclinno in parser.c can also be removed, it is used only for the LINENO hack.) This version produces accurate results: $((LINENO)) was made as accurate as the LINENO hack made ${LINENO} which is very good. That's why the LINENO hack is not yet completely removed, so it can be easily re-enabled. If you can tell the difference when it is in use, or not in use, then something has broken (or I managed to miss a case somewhere.) The way that LINENO works is documented in its own (new) section in the man page, so nothing more about that, or the new options, etc, here. This version introduces the possibility of having a "reference" function associated with a variable, which gets called whenever the value of the variable is required (that's what implements LINENO). There is just one function pointer however, so any particular variable gets at most one of the set function (as used for PATH, etc) or the reference function. The VFUNCREF bit in the var flags indicates which func the variable in question uses (if any - the func ptr, as before, can be NULL). I would not call the results of this perfect yet, but it is close.
2017-06-07 08:08:32 +03:00
case CTLNONL:
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
continue;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
case '?':
PR/7231: Havard Eidnes: Shell quoting/trimming problem
1999-03-26 18:49:34 +03:00
if (squoted && *q == CTLESC)
q++;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
if (*q++ == '\0')
return 0;
break;
case '*':
c = *p;
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
while (c == CTLQUOTEMARK || c == '*')
c = *++p;
A better LINENO implementation. This version deletes (well, #if 0's out) the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)). (Code to invert the LINENO hack when required, like when de-compiling the execution tree to provide the "jobs" command strings, is still included, that can be deleted when the LINENO hack is completely removed - look for refs to VSLINENO throughout the code. The var funclinno in parser.c can also be removed, it is used only for the LINENO hack.) This version produces accurate results: $((LINENO)) was made as accurate as the LINENO hack made ${LINENO} which is very good. That's why the LINENO hack is not yet completely removed, so it can be easily re-enabled. If you can tell the difference when it is in use, or not in use, then something has broken (or I managed to miss a case somewhere.) The way that LINENO works is documented in its own (new) section in the man page, so nothing more about that, or the new options, etc, here. This version introduces the possibility of having a "reference" function associated with a variable, which gets called whenever the value of the variable is required (that's what implements LINENO). There is just one function pointer however, so any particular variable gets at most one of the set function (as used for PATH, etc) or the reference function. The VFUNCREF bit in the var flags indicates which func the variable in question uses (if any - the func ptr, as before, can be NULL). I would not call the results of this perfect yet, but it is close.
2017-06-07 08:08:32 +03:00
if (c != CTLESC && c != CTLQUOTEMARK && c != CTLNONL &&
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
c != '?' && c != '*' && c != '[') {
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
while (*q != c) {
PR/7231: Havard Eidnes: Shell quoting/trimming problem
1999-03-26 18:49:34 +03:00
if (squoted && *q == CTLESC &&
q[1] == c)
break;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
if (*q == '\0')
return 0;
PR/7231: Havard Eidnes: Shell quoting/trimming problem
1999-03-26 18:49:34 +03:00
if (squoted && *q == CTLESC)
q++;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
q++;
}
}
Convert the pattern matcher from recursive to backtracking (from FreeBSD).
2017-04-26 20:43:33 +03:00
/*
* First try the shortest match for the '*' that
* could work. We can forget any earlier '*' since
* there is no way having it match more characters
* can help us, given that we are already here.
*/
bt_p = p;
bt_q = q;
break;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
case '[': {
Convert the pattern matcher from recursive to backtracking (from FreeBSD).
2017-04-26 20:43:33 +03:00
const char *savep, *saveq, *endp;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
int invert, found;
Convert the pattern matcher from recursive to backtracking (from FreeBSD).
2017-04-26 20:43:33 +03:00
unsigned char chr;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
endp = p;
if (*endp == '!')
endp++;
for (;;) {
A better LINENO implementation. This version deletes (well, #if 0's out) the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)). (Code to invert the LINENO hack when required, like when de-compiling the execution tree to provide the "jobs" command strings, is still included, that can be deleted when the LINENO hack is completely removed - look for refs to VSLINENO throughout the code. The var funclinno in parser.c can also be removed, it is used only for the LINENO hack.) This version produces accurate results: $((LINENO)) was made as accurate as the LINENO hack made ${LINENO} which is very good. That's why the LINENO hack is not yet completely removed, so it can be easily re-enabled. If you can tell the difference when it is in use, or not in use, then something has broken (or I managed to miss a case somewhere.) The way that LINENO works is documented in its own (new) section in the man page, so nothing more about that, or the new options, etc, here. This version introduces the possibility of having a "reference" function associated with a variable, which gets called whenever the value of the variable is required (that's what implements LINENO). There is just one function pointer however, so any particular variable gets at most one of the set function (as used for PATH, etc) or the reference function. The VFUNCREF bit in the var flags indicates which func the variable in question uses (if any - the func ptr, as before, can be NULL). I would not call the results of this perfect yet, but it is close.
2017-06-07 08:08:32 +03:00
while (*endp == CTLQUOTEMARK || *endp==CTLNONL)
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
endp++;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
if (*endp == '\0')
goto dft; /* no matching ] */
if (*endp == CTLESC)
endp++;
if (*++endp == ']')
break;
}
invert = 0;
Convert the pattern matcher from recursive to backtracking (from FreeBSD).
2017-04-26 20:43:33 +03:00
savep = p, saveq = q;
invert = 0;
if (*p == '!' || *p == '^') {
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
invert++;
p++;
}
found = 0;
Convert the pattern matcher from recursive to backtracking (from FreeBSD).
2017-04-26 20:43:33 +03:00
if (*q == '\0')
Fix problem with character classes matching a terminating NUL, from Henry Spencer.
1994-08-29 05:54:39 +04:00
return 0;
Convert the pattern matcher from recursive to backtracking (from FreeBSD).
2017-04-26 20:43:33 +03:00
chr = (unsigned char)*q++;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
c = *p++;
do {
A better LINENO implementation. This version deletes (well, #if 0's out) the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)). (Code to invert the LINENO hack when required, like when de-compiling the execution tree to provide the "jobs" command strings, is still included, that can be deleted when the LINENO hack is completely removed - look for refs to VSLINENO throughout the code. The var funclinno in parser.c can also be removed, it is used only for the LINENO hack.) This version produces accurate results: $((LINENO)) was made as accurate as the LINENO hack made ${LINENO} which is very good. That's why the LINENO hack is not yet completely removed, so it can be easily re-enabled. If you can tell the difference when it is in use, or not in use, then something has broken (or I managed to miss a case somewhere.) The way that LINENO works is documented in its own (new) section in the man page, so nothing more about that, or the new options, etc, here. This version introduces the possibility of having a "reference" function associated with a variable, which gets called whenever the value of the variable is required (that's what implements LINENO). There is just one function pointer however, so any particular variable gets at most one of the set function (as used for PATH, etc) or the reference function. The VFUNCREF bit in the var flags indicates which func the variable in question uses (if any - the func ptr, as before, can be NULL). I would not call the results of this perfect yet, but it is close.
2017-06-07 08:08:32 +03:00
if (c == CTLQUOTEMARK || c == CTLNONL)
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
continue;
Convert the pattern matcher from recursive to backtracking (from FreeBSD).
2017-04-26 20:43:33 +03:00
if (c == '\0') {
p = savep, q = saveq;
c = '[';
goto dft;
}
Add wctype(3) support to Shell Patterns. Obtained from FreeBSD.
2014-01-20 18:05:51 +04:00
if (c == '[' && *p == ':') {
found |= match_charclass(p, chr, &end);
if (end != NULL)
p = end;
}
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
if (c == CTLESC)
c = *p++;
Convert the pattern matcher from recursive to backtracking (from FreeBSD).
2017-04-26 20:43:33 +03:00
wc = (unsigned char)c;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
if (*p == '-' && p[1] != ']') {
p++;
if (*p == CTLESC)
p++;
Convert the pattern matcher from recursive to backtracking (from FreeBSD).
2017-04-26 20:43:33 +03:00
wc2 = (unsigned char)*p++;
if ( collate_range_cmp(chr, wc) >= 0
&& collate_range_cmp(chr, wc2) <= 0
)
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
found = 1;
} else {
Convert the pattern matcher from recursive to backtracking (from FreeBSD).
2017-04-26 20:43:33 +03:00
if (chr == wc)
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
found = 1;
}
} while ((c = *p++) != ']');
if (found == invert)
Convert the pattern matcher from recursive to backtracking (from FreeBSD).
2017-04-26 20:43:33 +03:00
goto backtrack;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
break;
}
sync with 4.4lite
1994-05-11 21:09:42 +04:00
dft: default:
PR/7231: Havard Eidnes: Shell quoting/trimming problem
1999-03-26 18:49:34 +03:00
if (squoted && *q == CTLESC)
q++;
Convert the pattern matcher from recursive to backtracking (from FreeBSD).
2017-04-26 20:43:33 +03:00
if (*q++ == c)
break;
backtrack:
/*
* If we have a mismatch (other than hitting the end
* of the string), go back to the last '*' seen and
* have it match one additional character.
*/
if (bt_p == NULL)
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
return 0;
Convert the pattern matcher from recursive to backtracking (from FreeBSD).
2017-04-26 20:43:33 +03:00
if (*bt_q == '\0')
return 0;
bt_q++;
p = bt_p;
q = bt_q;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
break;
}
}
}
/*
A better LINENO implementation. This version deletes (well, #if 0's out) the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)). (Code to invert the LINENO hack when required, like when de-compiling the execution tree to provide the "jobs" command strings, is still included, that can be deleted when the LINENO hack is completely removed - look for refs to VSLINENO throughout the code. The var funclinno in parser.c can also be removed, it is used only for the LINENO hack.) This version produces accurate results: $((LINENO)) was made as accurate as the LINENO hack made ${LINENO} which is very good. That's why the LINENO hack is not yet completely removed, so it can be easily re-enabled. If you can tell the difference when it is in use, or not in use, then something has broken (or I managed to miss a case somewhere.) The way that LINENO works is documented in its own (new) section in the man page, so nothing more about that, or the new options, etc, here. This version introduces the possibility of having a "reference" function associated with a variable, which gets called whenever the value of the variable is required (that's what implements LINENO). There is just one function pointer however, so any particular variable gets at most one of the set function (as used for PATH, etc) or the reference function. The VFUNCREF bit in the var flags indicates which func the variable in question uses (if any - the func ptr, as before, can be NULL). I would not call the results of this perfect yet, but it is close.
2017-06-07 08:08:32 +03:00
* Remove any CTLESC or CTLNONL characters from a string.
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
*/
void
Fixes from David Laight: - ansification - format of output of jobs command (etc) - job identiers %+, %- etc - $? and $(...) - correct quoting of output of set, export -p and readonly -p - differentiation between nornal and 'posix special' builtins - correct behaviour (posix) for errors on builtins and special builtins - builtin printf and kill - set -o debug (if compiled with DEBUG) - cd src obj (as ksh - too useful to do without) - unset -e name, remove non-readonly variable from export list. (so I could unset -e PS1 before running the test shell...)
2002-11-25 01:35:38 +03:00
rmescapes(char *str)
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
{
kill 'register'
1997-01-11 05:04:27 +03:00
char *p, *q;
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
p = str;
A better LINENO implementation. This version deletes (well, #if 0's out) the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)). (Code to invert the LINENO hack when required, like when de-compiling the execution tree to provide the "jobs" command strings, is still included, that can be deleted when the LINENO hack is completely removed - look for refs to VSLINENO throughout the code. The var funclinno in parser.c can also be removed, it is used only for the LINENO hack.) This version produces accurate results: $((LINENO)) was made as accurate as the LINENO hack made ${LINENO} which is very good. That's why the LINENO hack is not yet completely removed, so it can be easily re-enabled. If you can tell the difference when it is in use, or not in use, then something has broken (or I managed to miss a case somewhere.) The way that LINENO works is documented in its own (new) section in the man page, so nothing more about that, or the new options, etc, here. This version introduces the possibility of having a "reference" function associated with a variable, which gets called whenever the value of the variable is required (that's what implements LINENO). There is just one function pointer however, so any particular variable gets at most one of the set function (as used for PATH, etc) or the reference function. The VFUNCREF bit in the var flags indicates which func the variable in question uses (if any - the func ptr, as before, can be NULL). I would not call the results of this perfect yet, but it is close.
2017-06-07 08:08:32 +03:00
while (*p != CTLESC && *p != CTLQUOTEMARK && *p != CTLNONL) {
if (*p++ == '\0')
return;
}
q = p;
while (*p) {
if (*p == CTLQUOTEMARK || *p == CTLNONL) {
p++;
continue;
}
if (*p == CTLESC)
p++;
*q++ = *p++;
}
*q = '\0';
}
/*
* and a special version for dealing with expressions to be parsed
* by the arithmetic evaluator. That needs to be able to count \n's
* even ones that were \newline elided \n's, so we have to put the
* latter back into the string - just being careful to put them only
* at a place where white space can reasonably occur in the string
* -- then the \n we insert will just be white space, and ignored
* for all purposes except line counting.
*/
void
rmescapes_nl(char *str)
{
char *p, *q;
int nls = 0, holdnl = 0, holdlast;
p = str;
while (*p != CTLESC && *p != CTLQUOTEMARK && *p != CTLNONL) {
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
if (*p++ == '\0')
return;
}
A better LINENO implementation. This version deletes (well, #if 0's out) the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)). (Code to invert the LINENO hack when required, like when de-compiling the execution tree to provide the "jobs" command strings, is still included, that can be deleted when the LINENO hack is completely removed - look for refs to VSLINENO throughout the code. The var funclinno in parser.c can also be removed, it is used only for the LINENO hack.) This version produces accurate results: $((LINENO)) was made as accurate as the LINENO hack made ${LINENO} which is very good. That's why the LINENO hack is not yet completely removed, so it can be easily re-enabled. If you can tell the difference when it is in use, or not in use, then something has broken (or I managed to miss a case somewhere.) The way that LINENO works is documented in its own (new) section in the man page, so nothing more about that, or the new options, etc, here. This version introduces the possibility of having a "reference" function associated with a variable, which gets called whenever the value of the variable is required (that's what implements LINENO). There is just one function pointer however, so any particular variable gets at most one of the set function (as used for PATH, etc) or the reference function. The VFUNCREF bit in the var flags indicates which func the variable in question uses (if any - the func ptr, as before, can be NULL). I would not call the results of this perfect yet, but it is close.
2017-06-07 08:08:32 +03:00
if (p > str) /* must reprocess char before stopper (if any) */
--p; /* so we do not place a \n badly */
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
q = p;
while (*p) {
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
if (*p == CTLQUOTEMARK) {
p++;
continue;
}
A better LINENO implementation. This version deletes (well, #if 0's out) the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)). (Code to invert the LINENO hack when required, like when de-compiling the execution tree to provide the "jobs" command strings, is still included, that can be deleted when the LINENO hack is completely removed - look for refs to VSLINENO throughout the code. The var funclinno in parser.c can also be removed, it is used only for the LINENO hack.) This version produces accurate results: $((LINENO)) was made as accurate as the LINENO hack made ${LINENO} which is very good. That's why the LINENO hack is not yet completely removed, so it can be easily re-enabled. If you can tell the difference when it is in use, or not in use, then something has broken (or I managed to miss a case somewhere.) The way that LINENO works is documented in its own (new) section in the man page, so nothing more about that, or the new options, etc, here. This version introduces the possibility of having a "reference" function associated with a variable, which gets called whenever the value of the variable is required (that's what implements LINENO). There is just one function pointer however, so any particular variable gets at most one of the set function (as used for PATH, etc) or the reference function. The VFUNCREF bit in the var flags indicates which func the variable in question uses (if any - the func ptr, as before, can be NULL). I would not call the results of this perfect yet, but it is close.
2017-06-07 08:08:32 +03:00
if (*p == CTLNONL) {
p++;
nls++;
continue;
}
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
if (*p == CTLESC)
p++;
A better LINENO implementation. This version deletes (well, #if 0's out) the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)). (Code to invert the LINENO hack when required, like when de-compiling the execution tree to provide the "jobs" command strings, is still included, that can be deleted when the LINENO hack is completely removed - look for refs to VSLINENO throughout the code. The var funclinno in parser.c can also be removed, it is used only for the LINENO hack.) This version produces accurate results: $((LINENO)) was made as accurate as the LINENO hack made ${LINENO} which is very good. That's why the LINENO hack is not yet completely removed, so it can be easily re-enabled. If you can tell the difference when it is in use, or not in use, then something has broken (or I managed to miss a case somewhere.) The way that LINENO works is documented in its own (new) section in the man page, so nothing more about that, or the new options, etc, here. This version introduces the possibility of having a "reference" function associated with a variable, which gets called whenever the value of the variable is required (that's what implements LINENO). There is just one function pointer however, so any particular variable gets at most one of the set function (as used for PATH, etc) or the reference function. The VFUNCREF bit in the var flags indicates which func the variable in question uses (if any - the func ptr, as before, can be NULL). I would not call the results of this perfect yet, but it is close.
2017-06-07 08:08:32 +03:00
holdlast = holdnl;
holdnl = is_in_name(*p); /* letters, digits, _ */
if (q == str || is_space(q[-1]) || (*p != '=' && q[-1] != *p)) {
if (nls > 0 && holdnl != holdlast) {
while (nls > 0)
*q++ = '\n', nls--;
}
}
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
*q++ = *p++;
}
A better LINENO implementation. This version deletes (well, #if 0's out) the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)). (Code to invert the LINENO hack when required, like when de-compiling the execution tree to provide the "jobs" command strings, is still included, that can be deleted when the LINENO hack is completely removed - look for refs to VSLINENO throughout the code. The var funclinno in parser.c can also be removed, it is used only for the LINENO hack.) This version produces accurate results: $((LINENO)) was made as accurate as the LINENO hack made ${LINENO} which is very good. That's why the LINENO hack is not yet completely removed, so it can be easily re-enabled. If you can tell the difference when it is in use, or not in use, then something has broken (or I managed to miss a case somewhere.) The way that LINENO works is documented in its own (new) section in the man page, so nothing more about that, or the new options, etc, here. This version introduces the possibility of having a "reference" function associated with a variable, which gets called whenever the value of the variable is required (that's what implements LINENO). There is just one function pointer however, so any particular variable gets at most one of the set function (as used for PATH, etc) or the reference function. The VFUNCREF bit in the var flags indicates which func the variable in question uses (if any - the func ptr, as before, can be NULL). I would not call the results of this perfect yet, but it is close.
2017-06-07 08:08:32 +03:00
while (--nls >= 0)
*q++ = '\n';
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
*q = '\0';
}
/*
* See if a pattern matches in a case statement.
*/
int
Fixes from David Laight: - ansification - format of output of jobs command (etc) - job identiers %+, %- etc - $? and $(...) - correct quoting of output of set, export -p and readonly -p - differentiation between nornal and 'posix special' builtins - correct behaviour (posix) for errors on builtins and special builtins - builtin printf and kill - set -o debug (if compiled with DEBUG) - cd src obj (as ksh - too useful to do without) - unset -e name, remove non-readonly variable from export list. (so I could unset -e PS1 before running the test shell...)
2002-11-25 01:35:38 +03:00
casematch(union node *pattern, char *val)
{
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
struct stackmark smark;
int result;
char *p;
setstackmark(&smark);
argbackq = pattern->narg.backquote;
STARTSTACKSTR(expdest);
ifslastp = NULL;
Patches from Tor Egge (via Havard Eidnes) to fix various bugs in field splitting and combining. (Note: Some of this are not strictly bugs, but differences between traditional Bourne shell and POSIX.)
1999-01-25 17:20:56 +03:00
argstr(pattern->narg.text, EXP_TILDE | EXP_CASE);
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
STPUTC('\0', expdest);
p = grabstackstr(expdest);
PR/7231: Havard Eidnes: Shell quoting/trimming problem
1999-03-26 18:49:34 +03:00
result = patmatch(p, val, 0);
initial import of 386bsd-0.1 sources
1993-03-21 12:45:37 +03:00
popstackmark(&smark);
return result;
}
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
/*
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
* Our own itoa(). Assumes result buffer is on the stack
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
*/
STATIC char *
Fixes from David Laight: - ansification - format of output of jobs command (etc) - job identiers %+, %- etc - $? and $(...) - correct quoting of output of set, export -p and readonly -p - differentiation between nornal and 'posix special' builtins - correct behaviour (posix) for errors on builtins and special builtins - builtin printf and kill - set -o debug (if compiled with DEBUG) - cd src obj (as ksh - too useful to do without) - unset -e name, remove non-readonly variable from export list. (so I could unset -e PS1 before running the test shell...)
2002-11-25 01:35:38 +03:00
cvtnum(int num, char *buf)
{
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
char temp[32];
int neg = num < 0;
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
char *p = temp + sizeof temp - 1;
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
if (neg)
num = -num;
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
*p = '\0';
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
do {
*--p = num % 10 + '0';
Fixes to shell expand (that is, $ stuff) from FreeBSD (implemented differently...) In particular ${01} is now $1 not $0 (for ${0any-digits}) ${4294967297} is most probably now "" (unless you have a very large number of params) it is no longer an alias for $1 (4294967297 & 0xFFFFFFFF) == 1 $(( expr $(( more )) stuff )) is no longer the same as $(( expr (( more )) stuff )) which was sometimes OK, as in: $(( 3 + $(( 2 - 1 )) * 3 )) but not always as in: $(( 1$((1 + 1))1 )) which should be 121, but was an arith syntax error as 1((1 + 1))1 is meaningless. Probably some more. This also sprinkles a little const, splits a big func that had 2 (kind of unrelated) purposes into two simpler ones, and avoids some (semi-dubious) modifications (and restores) in the input string to insert \0's when they were needed.
2017-06-03 13:31:16 +03:00
} while ((num /= 10) != 0 && p > temp + 1);
I added the documented in the manual but not implemented variable expansions: ${#WORD} ${WORD%PAT} ${WORD%%PAT} ${WORD#PAT} ${WORD##PAT}
1995-01-23 09:33:03 +03:00
if (neg)
*--p = '-';
while (*p)
STPUTC(*p++, buf);
return buf;
}
Add new builtin `wordexp' to support wordexp(3). From FreeBSD. Provided in PR lib/26123. Approved by kleink@.
2004-07-13 19:05:59 +04:00
/*
* Do most of the work for wordexp(3).
*/
int
wordexpcmd(int argc, char **argv)
{
size_t len;
int i;
out1fmt("%d", argc - 1);
out1c('\0');
for (i = 1, len = 0; i < argc; i++)
len += strlen(argv[i]);
Use %zu in printf format for size_t value.
2009-11-27 13:50:04 +03:00
out1fmt("%zu", len);
Add new builtin `wordexp' to support wordexp(3). From FreeBSD. Provided in PR lib/26123. Approved by kleink@.
2004-07-13 19:05:59 +04:00
out1c('\0');
for (i = 1; i < argc; i++) {
out1str(argv[i]);
out1c('\0');
}
return (0);
}