--all command with --no-accept-gaps not failing gappy sequences

[digitensions]

--all command with --no-accept-gaps not failing gappy sequences

[kieranjol]

I’m a bit torn on this one. I’m leaning towards Joanna’s suggestion, as I’d imagine most gaps would indicate an error? I’m trying to think of an example where a gap is preferred and expected. K

…

On Mon 7 Feb 2022 at 12:27, Joanna White ***@***.***> wrote: Just an idea, as I know you're busy and this may be time consuming. Would it be better perhaps to remove '--accept-gaps' from the all command? Interested to hear from other users, but after speaking with colleagues here I know there was interest in RAWcooked failing gaps in sequences from business as usual workflows, as it may indicate fault in scanning or copying that we need to know about. At present we have three servers processing in house scans where we definitely want gaps to fail an encoding, and one server processing externally supplied legacy scans from LTO tape that frequently suffer from gaps. — Reply to this email directly, view it on GitHub <#362 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAITFPUZL7PJ3TEREXO3RWTUZ63BTANCNFSM5NJJWOHA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[JeromeMartinez]

--no-accept-gaps currently provides a warning and a question to the user if it is wished, and the -y automates the answer "yes" (-n would reject the processing).

I understand that this is not what is expected, so I'll change the behavior to something like that:

• if --no-accept-gaps, it is rejected,
• if --accept-gaps, it is accepted,
• if --ask-accept-gaps (which would be the default), question to the user or obey -y / -n.

[digitensions]

Thanks Jérôme! Sorry for wasting time, I twigged this today and was waiting for gappy sequence to test again. Thank you for confirming. Happy to close this!

…

On 4 Feb 2022, at 18:35, Jérôme Martinez ***@***.***> wrote:  --no-accept-gaps currently provides a warning and a question to the user if it is wished, and the -y automates the answer "yes" (-n would reject the processing). I understand that this is not what is expected, so I'll change the behavior to something like that: if --no-accept-gaps, it is rejected, if --accept-gaps, it is accepted, if --ask-accept-gaps (which would be the default), question to the user or obey -y / -n. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.

[JeromeMartinez]

Happy to close this!

Don't, I think it is relevant to avoid such surprise. Developers may have an idea in mind which makes sense to them but does not make sense to users, and a tool is for users o they have priority, so here current behavior needs to be changed if there is a better method.

If the proposal makes sense to users, I'll try to implement some options this way.

[digitensions]

Just an idea, as I know you're busy. Would it be better perhaps to default to '--no-accept-gaps' from the '--all' command? Interested to hear from other users, but after speaking with colleagues here I know there was interest in RAWcooked failing gaps in sequences from business as usual workflows, as it may indicate fault in scanning or copying that we need to know about.

At present we have three servers processing in house scans where we definitely want gaps to fail an encoding, and one server processing externally supplied legacy scans from LTO tape that frequently suffer from gaps.
Thank you!