There was this thing from 2017 that was supposedly a bug and fixed (didn't exactly apply to me). And also this from 2016-2018 that ultimately made me restart the gnome keyring daemon. Most people with this error have misconfigured permissions with their ssh keys or something...

But on those two cases Jupiter was opposed to Uranus, so your description doesn't apply (I sure hope that you understand that I am just kidding) :-) @AndrasDeak

What will be the default behaviour if I run this command in a terminal emulator in any Linux distribution (or any nix system)? Command: setsid sleep 10; exit. Does it exit quickly or wait for 10 seconds?

@Biswapriyo In Linux, it will exit immediately (also closing the interactive shell where the command was written), but the sub-shell that host the sleep command will persist for 10 seconds.

anybody got any ideas re this stackoverflow.com/questions/61706859/…

@Biswapriyo In most Unices, it would exit immediately, mostly because setised would not be found.

@barlop You have an unquoted command substitution on your command line. It will be split on the values of $IFS (and then filename globbing will happen on each generated word). If the output of your command does not contain any characters in $IFS (and no filename globbing characters), it will be passed as one single argument to your program.

which line is the unquoted command substitution?

oh I see `find .`

The find . command. If it was quoted, it would read `` "find ." `` or "$(find .)".

(Ugh, backticks in markup doesn't work well)

yeah

That would have been a better question for us on U&L than on SO, IMO.

On the other hand, it would be close as a duplicate.

well, I asked on there 'cos it had the C program

The C program behaves as any other script or program on Unix tho.

The question is more to do with quoting (and the effect of not quoting) arguments than with the actual C code.

I guess so.. I wasn't sure if scripts and executables and internal shell commands all split the command line the same way

It's the shell that does that, never the command itself.

So it always happens the same way.

if the command is written in C, then after the shell does whatever it does, the program splits it like that argsv

No, the shell perofrms the splitting of any unquoted strings on the command line, applies filename globbing to the split-up words, and executes the given command with the generated words as arguments.

argv[] in your C code is exactly what the shell put into it.

The program receives argv[]. It does not split it up further automatically somehow.

In Windows cmd, I heard that the shell does whatever it does then dumps the lot to the command and so this code would apply for windows gist.github.com/gartha1/faa7a31dd87960cf1964bcb1c429d7c2

@barlop I can't speak for Windows or how that is supposed to work. It's irrelevant as far as I'm aware.

would the shell do its interpretations then dump everything like one command line into the program or script? So then the program puts that into argv?

so the the shell isn't really splitting it into arguments?

The Unix shell splits the command line. It execute your command using execve() (most likely). This puts the command line arguments (not the command line itself) into argv[] for your command.

Which part of this is it you're having issues with?

just looking at how things work, not really having issues. thanks

@Kusalananda supposing it was a quoted command substitution, how does that change parsing?

$ echo -n "`echo abc`" | od -tcx1 <-- doesn't show a new line there

@barlop Command substitution removes trailing newlines. Compare it with

echo -n "`echo abc; echo d`" | od -tcx1

ah ok, thanks

What's the issue?

@Kusalananda No issue.I just try to get a good understanding of stuff. Thanks

That way it helps avoid issues in the long run!