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
<[email protected]> 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
