[PATCH] Use size_t for variable list size and length

[Roman Rakus]

see 
https://www.securecoding.cert.org/confluence/display/seccode/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow

Signed-off-by: Roman Rakus 
---
 variables.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/variables.h b/variables.h
index 84e92bb..7a6bd6f 100644
--- a/variables.h
+++ b/variables.h
@@ -95,8 +95,8 @@ typedef struct variable {
 
 typedef struct _vlist {
   SHELL_VAR **list;
-  int list_size;   /* allocated size */
-  int list_len;/* current number of entries */
+  size_t list_size;/* allocated size */
+  size_t list_len; /* current number of entries */
 } VARLIST;
 
 /* The various attributes that a given variable can have. */
-- 
1.7.11.7

requested dry-run mode for bash.

[Robert Durkacz]

This is a request for a new feature. Perhaps there are good reasons
why it can't be done, but from the outside looking in it seems
possible, and I have taken into account advice from the bash help
mailing list.

Could there be a dry-run option for bash. A dry-run option would be
something akin to a combination of the -x and -n options. When a
script is processed by bash in dry-run mode there would be output to
stdout or stderr the sequence of commands that bash determines to run,
something like -x, but the commands are not in fact executed, as with
-n

If the output were to be captured as a script, that script itself
could be run by a normal invocation of bash, giving the same result,
output and side-effects, as the original script would give. If the
captured script were executed in dry-run mode the output should be the
same as the input.

make has a dry run option as described,  "-n".

A typical use would be determine what a complicated script, like
libtool, will end up doing.

>From googling, people have posted suggestions as to how to achieve
this behaviour in scripts. This indicates that there is a demand for
such a feature. An allied question is also raised: In -x mode, where
command lines are echoed but unfortunately any applicable redirections
of stdout and stdin are lost.

Some details and difficulties have been anticipated.

1. Which commands are dry-run?
Only external commands are candidates for dry-running. Moreover, the
user must have the chance somehow to specify which commands are
executed and which not.
For the use-case of building code (ie with make, libtool and those
kind of things) /usr/bin/ls should proceed, so as to see what files
are present, which are out of date etc, but usr/bin/gcc should be
dry-run, just the recommended command line listed to stdout.

2. What to do about variables set by commands when the commands are not run.
Example.
 command   # not executed
 if $? another_command # return value of previous command not known
Another example
 var= `command`# command not executed
 another_command $var  # $var not known

Either way bash is being asked to read a variable that is invalid
because the step to set it was skipped.

Suggested response.
 bash treats this as an error (similar to -u option) and would most
likely exit (as in -e)
 However the user may want to specify that 0 is assumed for $? for
commands not executed.