Re: extcap command line parameter format

[Roland Knall <rknall () gmail com>]

Sorry for the late way-in. 

The main intent for extcap-version was to provide a way, so that we can change commands calling the utility without 
loosing compatibility to older utilities. Mainly to introduce or change commands, like we did with the toolbar. 

As main extcap development was done with Python, and there with argparse, I never came across this particular issue. 

Although I can see the benefit of the env variable, I would prefer handling this with commands. Env variables might not 
work as intended across all platforms necessarily and therefore provides just another test scenario. 

Cheers
Roland

> Am 29.07.2018 um 16:59 schrieb Jaap Keuter <jaap.keuter () xs4all nl>:
>
>
>
> > On 27 Jul 2018, at 22:50, Guy Harris <guy () alum mit edu> wrote:
> >
> > On Jul 27, 2018, at 10:40 AM, Guy Harris <guy () alum mit edu> wrote:
> >
> > > Oh, and another thing not to do:
> > >
> > >    Don't repurpose a command-line flag intended for one purpose for another unrelated purpose.
> > >
> > > For example, don't repurpose a command-line flag (for concreteness, let's pick the hypothetical example of a flag 
> > > called "--extcap-version"), intended for one purpose (in this hypothetical example, used to ask a program to report 
> > > its version number), for a separate purpose (in this hypothetical example, used to tell a program the version 
> > > number of the program running that other program), with the two unrelated meanings distinguished based on whether 
> > > the flag has an argument or not.
> > >
> > > I.e., for Wireshark 3.0, let's do the latter function with --extcap-wireshark-version X.Y or 
> > > --extcap-wireshark-version=X.Y, with --extcap-version *never* taking an argument and *always* meaning "report your 
> > > version number" and with --extcap-wireshark-version *always* taking an argument and *always* meaning "here's the 
> > > version of Wireshark that's running you".
> >
> > Unfortunately, *that* means that Wireshark 3.0 running an older extcap program that doesn't know about 
> > --extcap-wireshark-version may fail when run with that flag; at least with --extcap-version used for that purpose, 
> > the argument parser, *if* it doesn't fail if the option has a value, will just cause it to print the version of the 
> > program.
> >
> > Now, that might *also* cause an issue, with the extra output.
> >
> > How about we pass the Wireshark version as an *environment variable* - EXTCAP_WIRESHARK_VERSION - so that:
> >
> >    programs that don't know about it won't care, and will work with pre-3.0 and 3.0-and-later Wiresharks;
> >
> >    programs that do know about it *AND* that don't bogusly assume it's always set will somehow do the right thing if 
> > run by a pre-3.0 Wireshark.
>
> I agree with you here, it cause[sd] some confusion to figure out what this parameter is supposed to do.
>
> Problem is we’ll have to cater to any reasonable capable scripting language too. Python’s ‘argparse’ package is up to 
> the task, but will others? 
>
> As for environment variables, will they be passed on into possible sub shells? We don’t know because we don’t define 
> those. Does that work on Windows, where it is advised to use a wrapper script for python code.
>
> Thanks,
> Jaap
>
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe