Incorrect expansion of a program argument that is a special character?

Russell VT russellvt@gmail.com
Wed Jul 21 12:18:56 GMT 2021


Note that Powershell and BASH wildcard (globbing) may be notably different,
which includes how items may be "escaped" to prevent such globbing
operations.

Moreover, in a UN*X shell, it is generally thought that it's the user's
responsibility to declare how how file expansion should work, generally
defaulting to the "one or more" presence (where true regular expressions
use an asterisk as "zero or more"). In this way, shells and general regular
expressions may differ.

TLDR; In any environment, "arguments" are different between the command
line, and the program itself.

Basically, you need to understand how any given shell will pass arguments
to your program, and that exercise is generally outside of general
executable-type discussion (ie. it is almost a "religious war" as to how
various shells may process arguments, regular expressions, or wildcards ...
along with what options a user may specify to change the behaviour)

Do you have an example of where the program functions as-expected, along
with examples as to how the identical binary functions differently in
other environments?

Hope that lights a few lightbulbs for ya!

Russell VT


On Wed, Jul 21, 2021 at 4:44 AM Ev Drikos via Cygwin <cygwin@cygwin.com>
wrote:

> Hello,
>
> When I run the program below from my home directory in a PowerShell
> Console (Windows 8-1) I've to use an extra backslash character as
> shown below or the star is expanded. Which happens only when the
> program has been compiled in Cygwin.
>
> Is this a bug or a known feature?
>
> Ev. Drikos
>
> ----------------------------------------------
> PS C:\Users\suser> .\args.exe '\*'
>
> *
> argc=1
> PS C:\Users\suser>
> ----------------------------------------------
>
> #include <stdio.h>
> int main(int argc, char *argv[]){
> int i;
> for (i=1; i < argc; i++) {
>   printf("\n%s",argv[i]);
> }//for
>  printf("\nargc=%d\n",argc-1);
> return 0;
> }
>
> --
> Problem reports:      https://cygwin.com/problems.html
> FAQ:                  https://cygwin.com/faq/
> Documentation:        https://cygwin.com/docs.html
> Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
>


-- 
Russell M. Van Tassell <russellvt@gmail.com>


More information about the Cygwin mailing list