Infer encode/decode (major changes)

[jyn514]

Assign defaults after inferring argument

• If arguments are specified, easier to infer
• If not, it's clear that no change was made (as opposed to the user specifying the default)
• Use dictionary (called 'defaults') to specify
• Note: filename has to be evaluated second because it depends on input

Quit if no arguments given Many layers of checks to infer arguments Decisions made as follows: (assuming encode/decode not passed)

• editor given -> decode
• compresstype given -> encode
• compresslevel given -> encode
• chunklevel given -> encode
• filename given -> encode
• no output: -> encode (why?)
• no input and interactive -> decode (why?)
• input and not interactive -> quit with error
• input and output -> quit with error

Other refactoring: find_editor() is its own function (simplifies logic by a great deal)

[bx-r0]

Does "Quit if no arguments given" prevent the use of the tool being used with piping?

[jyn514]

Only if no arguments are given on the command line. This behavior is specified by https://github.com/charlesdaniels/bitshuffle/issues/1. The tools runs correctly if arguments are specified and input is piped.

[jyn514]

You make a good point though- if it's piped, the user won't be looking for help, so we should consider inferring an argument.

Also, I want to refactor the control structure, it has all the tabs because of design decision I never commited

[charlesdaniels]

no output: -> encode (why?)

I don't remember specifying this... I can't think of a justification for it; unless the user also specified --input, in which case it makes sense.

no input and interactive -> decode (why?)

This only makes sense if standard in is a tty; it means the use is running interactively, and thus that they want their $VISUAL to open so they can paste data in.

input and not interactive -> quit with error

Huh? This would imply the user is using it with a pipeline. For example bitshuffle --input /some/file | some other script. One specific use case for this functionality would be where the input needs to come from a named pipe (although the user could easily direct it to stdin.

input and output -> quit with error

This is not an error condition, it implies that encoded packets are to be read from the input file specified and written to the specified output file.

find_editor() is its own function (simplifies logic by a great deal)

This was a good idea. I tried to find a library to do this, but could not.

You make a good point though- if it's piped, the user won't be looking for help, so we should consider inferring an argument.

Just because stdin is not a tty does not mean bitshuffle is running in a pipeline (although it is a strong indicator for the purpose of heuristics). Also, the help message is printed on stderr (as far as I know) which would not be captured by the pipe without the user specifically telling the pipe to capture it.

[jyn514]

To clarify, are these the changes you propose to the pull request?

input and no output -> encode input and output -> decode

As an aside: We should probably find a way to describe input/output as required in the help message, it's very uninformative otherwise.

[charlesdaniels]

To clarify, are these the changes you propose to the pull request? input and no output -> encode input and output -> decode

Yes, that is correct.

As an aside: We should probably find a way to describe input/output as required in the help message, it's very uninformative otherwise.

Yes, I'm planning to re-work some of the verbiage around this project at some point, there are a number of terms which are used in inconsistent or unclear ways.

[jyn514]

Merged this into dev; too many changes for it to go straight to master.

[charlesdaniels]

All of the inference considerations that we discussed have been implemented as of c4a0290

Note that I decided that having --input AND --output simultaneously should not imply anything special.