[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-bash] dry run
From: |
Robert Durkacz |
Subject: |
Re: [Help-bash] dry run |
Date: |
Tue, 20 Nov 2012 12:30:51 +1100 |
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 think I can imagine an answer to this. I am influenced by 'make', by
the way, which in dry run mode simply assumes all commands return
successfully, but that will not do for bash dry run. Indeed I could
matters worse by postulating
foo=`command1`
command2 $foo
$foo is simply unknown if command1 is not run
I would like to rephrase your example as
complex_command
if $? ...
Either way bash is being asked to read a variable that is invalid
because the step to set it was skipped.
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.
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.
> That said, you might be interested in the bashdb project,
I will look into that as well.
-RD