Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Calling the “--status” flag with a LOGBASE #44

Closed
tschettervictor opened this issue Aug 31, 2024 · 2 comments
Closed

Calling the “--status” flag with a LOGBASE #44

tschettervictor opened this issue Aug 31, 2024 · 2 comments

Comments

@tschettervictor
Copy link
Collaborator

Since the FreeBSD port installs the application to $PATH, what’s the best way to call the “--status” command due to the fact that the default $PATH is not where the “config.sh” or the “logs” directory are stored?

You could do “LOGBASE=/path/to/logs zfs-replicate --status” or “zfs-replicate -s /path/to/config.sh”
Both work.

@aaronhurt
Copy link
Owner

aaronhurt commented Aug 31, 2024

They do both work, and all of these should work, but I think some make more sense than the others.

These make sense using environment variables.

LOG_BASE=/path/to/logs zfs-replicate.sh --status
LOG_BASE=/path/to/logs zfs-replicate.sh -s

Putting the config first in a historic fashion makes sense, but it's odd syntax.

zfs-replicate.sh /path/to/config.sh --status
zfs-replicate.sh /path/to/config.sh -s

This really doesn't make sense at all. It works, but is really awful syntax. The config looks like an argument to the status flag.

zfs-replicate.sh --status /path/to/config.sh
zfs-replicate.sh -s /path/to/config.sh

If you want to pass the config to the command you should use an option for both the config and status.

zfs-replicate.sh --config /path/to/config.sh --status
zfs-replicate.sh -c /path/to/config.sh -s

You can also mix and match -s with --config and --status with -c, but the point being leaving the config dangling is odd syntax and is only supported for historical reasons. The order of the options also doesn't matter.

aaronhurt added a commit that referenced this issue Sep 1, 2024
In light of the discussion in #44, option parsing needs to be more
strict. We shouldn't allow an orphaned config at the end of a line that
looks like an option to another argument. This commit ensures that the
config is either passed FIRST, or via the -c/--config option. It also
does full argument validation before calling showStatus or showHelp.
@aaronhurt
Copy link
Owner

We shouldn't allow dangling configs, I've fixed this in #45

aaronhurt added a commit that referenced this issue Sep 1, 2024
In light of the discussion in #44, option parsing needs to be more
strict. We shouldn't allow an orphaned config at the end of a line that
looks like an option to another argument. This commit ensures that the
config is either passed FIRST, or via the -c/--config option. It also
does full argument validation before calling showStatus or showHelp.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants