Re: [Help-bash] dry run

[DJ Mills]

On Mon, Nov 19, 2012 at 8:30 PM, Robert Durkacz <address@hidden> wrote:

On Tue, Nov 20, 2012 at 1:03 AM, Eric Blake <address@hidden> wrote:

> A little thought would show why this will never be implemented.  What
> would such an option output for the following:
>
> if complex_command; then
>   foo=command1
> else
>   foo=command2
> fi
> $foo args
>

> On the line for $foo args, there is no way to know what $foo expands to...

I would like to rephrase your example as
 complex_command
 if $? ...

 
The original version is better here. There's no point in running "complex_command", then
running ANOTHER command to test its exit status. Just test the status of the command in
the first place, as Eric did. The other issue with testing $? like that is if errexit or an ERR
trap are used. The command isn't actually checked there, and a non-zero exit status would
trigger ERR. With "if command", that is not the case.

The user would have to be satisfied if bash --dryrun detected an error
and exited when asked to read an invalid variable. The user could then
adjust the script, explicitly setting the variable in question or
perhaps by temporarliy exiting dry run mode, and try again.

The example Eric gave is fundamental to how bash works. You couldn't really have any
variables that aren't hardcoded without the script exiting... I don't see how that would be
particularly useful. Even '[' is a command... essentially, you couldn't have any conditions if
you want the dry run to succeed. As you said, you obviously can't assume everything is true.
So the only other option is to actually run the commands to test the exit statuses, at which
point it's clearly not a dry run any more. Unless you can propose another solution?

 

To support this I suppose would require an extension to bash in that
it must distinguish an additional variety of undefined variable, the
type that is undefined because it is invalid. It would treat a read of
the second type as an error just as it may optionally treat a read of
the first type as an error.

I'm not sure what you mean by this... what would consider "invalid?" How would it be determined?
 

> That said, you might be interested in the bashdb project,

I will look into that as well.

-RD

That's really your best bet, I think. Bash (and shell in general) is very unique, and what works with
other languages very often doesn't work with shell scripting.

-DJ