Subject | non-interactive gbak |
---|---|
Author | ldeller_work |
Post date | 2008-12-04T06:16:12Z |
Hi,
I have found that gbak is currently not safe to use from a
non-interactive script, because it might prompt for user input under
certain conditions, eg
- when backing up to a file and the target disk becomes full
- when backing up to stdout which is piped to another command which
terminates prematurely (windows only, not linux)
- when restoring from stdin which is piped from another command which
terminates prematurely
Here is an example of a prompt produced in the first situation:
Done with volume #1, "/path/to/output.fbk" Press
return to reopen that file, or type a new
name followed by return to open a different file. Name:
It is actually quite hard to circumvent this as gbak tries very hard
to get real user input (by opening /dev/tty on linux or CONIN$/CONOUT$
on windows).
What are the chances of adding a new flag to gbak asking it to run
non-interactively? I would expect it to terminate with an error in
the above situations when run in non-interactive mode.
I could even have a go at implementing this myself if the idea doesn't
get shot down here.
Thanks,
Luke.
I have found that gbak is currently not safe to use from a
non-interactive script, because it might prompt for user input under
certain conditions, eg
- when backing up to a file and the target disk becomes full
- when backing up to stdout which is piped to another command which
terminates prematurely (windows only, not linux)
- when restoring from stdin which is piped from another command which
terminates prematurely
Here is an example of a prompt produced in the first situation:
Done with volume #1, "/path/to/output.fbk" Press
return to reopen that file, or type a new
name followed by return to open a different file. Name:
It is actually quite hard to circumvent this as gbak tries very hard
to get real user input (by opening /dev/tty on linux or CONIN$/CONOUT$
on windows).
What are the chances of adding a new flag to gbak asking it to run
non-interactively? I would expect it to terminate with an error in
the above situations when run in non-interactive mode.
I could even have a go at implementing this myself if the idea doesn't
get shot down here.
Thanks,
Luke.