could someone explain again how to get command line info from linux and PLEASE do not refer me to FAQ which is not a very clear explanation.

on the stack is argc, then argv so you should be able to POP them into registers - right?
pop ecx ;count
pop ebx ;address of first arg (filename)

so, if the argument on command line a filename, should I just always refer to it by the pointer OR
is it better to move the whole thing into another area - (movsb loop) and how do I know when I get
to the end? check for a space(32), or LF(10) or null(00), or all three.

mov eax, 5 ;sys_open
;;; mov ebx, filename ;pointer to filename NOT NEEDED because i popped it off the stack???
mov ecx, 0 ;read only access mode
mov edx, 0777 ;file permissions (read, write, execute by all)
int 0x80
mov [fd_in], eax ;error handling

You can leave the argv parameters on the stack, they will be safe there, so no need to move them elsewhere.

They are always terminated by NULL (0x00), nothing else.

The argv list is a table of pointers, so they aren't the strings themselves.

[esp+0] = argc
[esp+4] = pointer to first string (arg = 0)
[esp+8] = pointer to next string (arg = 1)
;...
[esp+argc*4] = pointer to last string (arg = argc-1)
[esp+argc*4+4] = null pointer
[esp+argc*4+8] = some other tables are also stored here

i got it, thx

On 64 bit if you write main (rdi->argc, rsi->argv pointer)
without main is same, on RSP.

For anyone familiar with Windows:

It might be surprising to learn that filenames in Linux can have any byte values except null and slash. So that includes CR, LF, space, 0xff, etc. And there is no default encoding, just raw byte values.

If the code tries to do text processing on the filename then it needs to be aware of this fact to avoid weird results. You can't simply assume ASCII printable characters only.

Displaying error message to the user that blindly copy the filename to the output can create unusual effects. Some real fun can be had by putting VT100 console escape sequences in the name.

Worse is when the filename contains newlines ('\n') and then you process the output line-by-line assuming it's a different filename. It can actually cause security vulnerabilities, a LOT of shell scripts and dumb programs suffer from it.

That's mainly the reason most GNU core tools have a -z option to delimit filenames in the output by NUL chars '\0' instead of newline.

IMO it was a mistake to allow newlines in filenames. Nobody really uses them except for malware.

With Windows when using the raw kernel functions to access an NTFS volume, it is possible to make a filename with null characters (0x0000).

Then, from a normal user program, it becomes impossible to open, delete, rename, move, etc, the file.

This is the same for registry key names.

Windows makes this possible because it stores the length of the name, and doesn't search for a terminator character. And since the APIs receive and return a null terminated string from/to the user code, then there is no way to work with the null.

Some programs have used this to detect if the user is trying to extend a free trial by deleting and reinstalling the files and registry keys. But that will fail to remove the "secret" null named file/key without using some deep level utility.