[PLUG] problem encountered with argv[] change when a local file named "1" is inserted into the file system
American Citizen
website.reader3 at gmail.com
Sat Dec 16 21:21:23 UTC 2023
Another person pointed out to me that the bash shell is making an escape
on hitting the brackets and trying to come up with a string match to the
files in the local directory, sort of like using the ls command "ls
*txt" to match on any txt file. I incorrectly assumed that the bracketed
group of characters was a string word, acting like a normal character set.
What is also interesting to me, is that this worked like a normal
character string and the bracketed characters were used exactly as they
were in the shell command, without interpretation in being passed to the
argv argument list.
Thanks again, Reid, for your reply.
Randall
On 12/16/23 13:04, American Citizen wrote:
> Reid
>
> Thank you for the reply. I could use quotes or tics or backslash the
> brackets. I have not encountered this problem before, where a file
> named "1" would cause the problem and I am still curious as to why and
> how the shell picked up the file name as apparently what is inside the
> brackets doesn't seem to stop this odd behavior, I changed the inside
> to [1,2,3,4,5] for example, but the program still crashed. I noticed
> that [20,20,20,20,20] and [30,30,30,30,30] also works fine, apparently
> the first two characters of "[1" trigger this reaction when the file
> "1" exists in the local directory.
>
> Randall
>
> On 12/16/23 11:35, Reid wrote:
>>
>>
>>
>>
>> Sent with Proton Mail secure email.
>>
>> On Saturday, December 16th, 2023 at 11:26 AM, American Citizen
>> <website.reader3 at gmail.com> wrote:
>>
>>
>>> Hello:
>>>
>>> I bumped into a curious problem with the argv variables changing,
>>> when a
>>> certain file named "1" is added into the local directory of the
>>> executable.
>>>
>>> Here is the test file, a simple program named test.c
>>>
>>>> #include <stdio.h>
>>>> #include <string.h>
>>>>
>>>> int main(int argc, char **argv) {
>>>>
>>>> int i=1;
>>>> //int STDIN = 1;
>>>>
>>>> char INCURV[1024] = {'\0'};
>>>>
>>>> while(i<argc) {
>>>> if (!strcmp(argv[i],"-curve")) {
>>>> printf("we are here \n");
>>>> //strcpy(INCURV,argv[i+1]); STDIN=0; i+=2;
>>>> }
>>>> i+=1;
>>>> }
>>>> return 0;
>>>> }
>>> I compile this file as
>>>
>>> % gcc -o wack test.c -ggdb
>>>
>>> (it is too easy to wipe out the source file if the object name almost
>>> matches)
>>>
>>> gcc is gcc version 7.5.0 (SUSE Linux)
>>>
>>> I have the gdb debugger stop on line 13 "printf("we are here\n");"
>>>
>>> Using input to the command:
>>>
>>> % wack -arderivs -curve [0,0,0,-1156,0]
>>>
>>> when no file named "1" exists in the directory then argv looks okay
>>>
>>> argv[0] = "/../../wack"
>>>
>>> argv[1] = "-arderivs"
>>>
>>> argv[2] = "-curve"
>>>
>>> argv[3] = "[0,0,0,-1156,0]"
>>>
>>> argv[4] = 0x0
>>>
>>> which is all fine and well.
>>>
>>> I used the touch command to create file "1" in the local directory
>>>
>>> % touch 1
>>>
>>> and restart the gdb debugger.
>>>
>>> argc count = 4 as expected
>>>
>>> but argv[3] = "1"
>>>
>>> Is this a bug in c?
>>>
>>> Why is argv[3] changed?
>> It's a shell issue, not a C issue. The shell is interpreting
>> something in the square-bracketed argument as special characters. To
>> avoid it, put the argument in quotes.
>>
>> (gdb) r -arderivs -curve 1
>> The program being debugged has been started already.
>> Start it from the beginning? (y or n) y
>> Starting program: /tmp/wack -arderivs -curve 1
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib64/libthread_db.so.1".
>>
>> Demo:
>>
>> (gdb) r -arderivs -curve [0,0,0,-1156,0]
>> ...
>> Breakpoint 1, main (argc=4, argv=0x7fffffffd568) at test.c:6
>> 6 int i=1;
>> (gdb) p argv[3]
>> $8 = 0x7fffffffd99f "1"
>>
>> (gdb) r -arderivs -curve "[0,0,0,-1156,0]"
>> ...
>> Breakpoint 1, main (argc=4, argv=0x7fffffffd558) at test.c:6
>> 6 int i=1;
>> (gdb) p argv[3]
>> $9 = 0x7fffffffd991 "[0,0,0,-1156,0]"
>>
>>
>>> Randall
More information about the PLUG
mailing list