XTeve on freenas

[Tigersharke]

If you enter any command on the command line, it is read and interpreted by the shell. The shell sees a single question mark, tries to match the entire string to a local file name, doesn't find any, and complains with "no match". Wget isn't even executed.

Second, what's so hard about typing w g e t <space> ' ' <cursor-left> <paste URL in> <enter>?

Laziness of course but that is a method (solution) I never would have considered. As for the shell message, I don't understand why it accepts a space as though it were quoted as I'd expect would be necessary for a file name, but the error is truncated after that first space in the error message. I can accept that that is how it is, I'll just need to "file away" this exception to a perceived rule for future.

Code:

# why are you so damned lazy?
why: No match.
# why\ are\ you\ so\ damned\ lazy?
why are you so damned lazy?: No match.

 

[Patrick M. Hausen]

The shell cut's your command line into pieces.

In the first example:
1. why
2. are
3. ...
6. lazy?

So it "thinks" you want it to execute the "why" command with paramaters "are", "you", "so", "damned", plus whatever "lazy?" expands to in your current directory. It cannot find any files starting with "lazy" followed by exactly one character, so it says "I cannot execute the 'why' command on your behalf because that wildcard pattern does not match".

Second example:
1. "why are you so damned lazy?" as a single string.

Again it looks for something matching "why are you so damned lazy" including the spaces and followed by exactly a single character. Then it complains that it cannot execute the "why are you so damned lazy?" command, because again - "no match". If you would create a file named "why are you so damned lazyX" in your current directory, the expansion would succeed, but it would error out with "command not found", because the current directory is not in the command search path.

The fundamental principle is that the command line is first completely cut into tokens and all wildcards expanded - and then the shell tries to execute whatever is the first token. In the first case "why", in the second case "why are you so damned lazyX", if that file is present. If it isn't, the expansion fails, so it does not even try to execute anything.

The final command in Unix never sees the original command line. It get's a neat array of preprocessed single arguments.

If you have files

aa
ab
ac

and you type ls a* , /bin/ls never sees "a*" It gets three separate arguments, "aa", "ab", and "ac", respectively.
That's the reason why something like mv *.txt *.bak, which works fine in MS-DOS, can never work in Unix. If you have

a.txt
b.txt

and execute mv *.txt *.bak, the shell turns this into mv a.txt b.txt *.bak - provided there are no ".bak" files anywhere - and then rightfully complains that that does not make sense and again aborts with "no match".

 

[Tigersharke]

The shell cut's your command line into pieces.

In the first example:
1. why
2. are
3. ...
6. lazy?

So it "thinks" you want it to execute the "why" command with paramaters "are", "you", "so", "damned", plus whatever "lazy?" expands to in your current directory. It cannot find any files starting with "lazy" followed by exactly one character, so it says "I cannot execute the 'why' command on your behalf because that wildcard pattern does not match".

Second example:
1. "why are you so damned lazy?" as a single string.

Again it looks for something matching "why are you so damned lazy" including the spaces and followed by exactly a single character. Then it complains that it cannot execute the "why are you so damned lazy?" command, because again - "no match". If you would create a file named "why are you so damned lazyX" in your current directory, the expansion would succeed, but it would error out with "command not found", because the current directory is not in the command search path.

The fundamental principle is that the command line is first completely cut into tokens and all wildcards expanded - and then the shell tries to execute whatever is the first token. In the first case "why", in the second case "why are you so damned lazyX", if that file is present. If it isn't, the expansion fails, so it does not even try to execute anything.

The final command in Unix never sees the original command line. It get's a neat array of preprocessed single arguments.

If you have files

aa
ab
ac

and you type ls a* , /bin/ls never sees "a*" It gets three separate arguments, "aa", "ab", and "ac", respectively.
That's the reason why something like mv *.txt *.bak, which works fine in MS-DOS, can never work in Unix. If you have

a.txt
b.txt

and execute mv *.txt *.bak, the shell turns this into mv a.txt b.txt *.bak - provided there are no ".bak" files anywhere - and then rightfully complains that that does not make sense and again aborts with "no match".

Thank you for your very thorough and complete explanation, it helps a lot. Obviously I learned something today and that is always a big plus. :)

 

[Patrick M. Hausen]

If you are looking for a rather fun book to browse in a leisurely way and learn a lot about Unix intricacies and historical artefacts, I recommend "Unix Power Tools" by O'Reilly. Last edition was published in 2002 so it's simultaneously completely outdated and absolutely timeless. You can learn a lot about the whence's and why's and it's written in a fun style and encourages picking topics instead of reading back to back.

The chapters on the Bourne shell and the C shell are especially valuable in our current context.

 

[SamCam]

Thanks for the detailed explanations guys, much appreciated!

 

[profzelonka]

Hi,
Thank you so much for your answer, I'm in hard work time during this period sorry for my too late replay.
I'm agree with you when you talk you running as no root user, my logs show problems about root user I used when I begin xteve.

Now I take the time to make it work, and I try to install xteve with no root user, where I have problem when trying to start xteve message say

Code:

root@xteve-server:/etc/rc.d                                                # service xteve start
starting xteve...
root@xteve-server:/etc/rc.d                                                # /home/xteve/xteve: Permission

I thing you had do something at user creation I don't understood right now.
To have better visibility and not long explanation I will recreate new jail and past my raw step-by-step installation of xteve, probably you will see something I don't saw or don't know yet.

Hey did you ever resolve this issue? I also can't figure out how to run it correctly, as user or root.
Correct me if I'm wrong everyone, but if it's in a separate jail running as root shouldn't be a problem. I can't figure out what the rc.d/xteve fiel contents would be for root tho.. Nothing I try works, but I am able to manually run "service xteve start" as root.