Faculty of Engineering and Mathematical Sciences 
Not logged in (login)

help4407


This forum is provided to promote discussion amongst students enrolled in Open Source Tools and Scripting (CITS4407).
 
Options:
RSS cloud
Jump to:

lec # wk 10 File Attributes - Square Bracket command external or internal

14 of 390 articles shown, currently no other people reading this forum.
photo
From: Alastair H.
Date: Tue 9th Jun, 11:15am
Actions: 
        Login-to-reply

 

The lecture states that historically the shell didn't have many things built into it, 
like the square bracket command and ls. In modern times, does the square bracket 
command now sit within the shell? - or is it still external. I wonder because it 
looked like it was external, sitting in the /bin directory. Thanks.

lec # wk 10 File Attributes - Square Bracket command external or internal

photo
From: David M.
Date: Tue 9th Jun, 4:26pm
Actions: 
        Login-to-reply

 

The command "test" or "[" is available both as an external command and as a Bourne
shell built-in command (and therefore as a bash built-in also). (As I recall they
can differ slightly in their supported options.)

See the bash documentation <https://www.gnu.org/software/bash/manual/html_node/Bourne-Shell-Builtins.html#Bourne-Shell-Builtins> for 

lec # wk 10 File Attributes - Square Bracket command external or internal

photo
From: David M.
Date: Tue 9th Jun, 4:36pm
Actions: 
        Login-to-reply

 

PS I meant the built-in and external versions of "test" may differ.
The external commmands "test" and "[" are links to the same external command.

lec # wk 10 File Attributes - Square Bracket command external or internal

photo
From: Christopher M.
Date: Tue 9th Jun, 5:15pm
Actions: 
        Login-to-reply

 

On my Ubuntu Linux system, the commands [ and test both exists (now) in /usr/bin, but are not links 
to each other (and different sizes).  Interestingly  'man test'  provides the online documentation 
for both.  On macOS /bin/[ and /bin/test  are the same binary (but still not linked ?).

On Linux, you can see all the bash builtin commands with    man bash-builtins
on macOS with  man builtins

Included in these builtins, familiar to us, are - [, alias, cd, echo, expo, eval, exit, pwd, and 
read.  Some of these previously existed as external commands, some *must* be internal commands.

lec # wk 10 File Attributes - Square Bracket command external or internal

photo
From: David M.
Date: Tue 9th Jun, 5:26pm
Actions: 
        Login-to-reply

 

Sometimes the same executable file supports multiple commands and executes the
one it was called with based on value of the program name (argv[0]) passed to it.
E.g. executable file X may be linked to by "a" and "b". When you run command "a"
the system runs command X with program name (argv[o]) set to  "a" but if you run
command "b" the system runs X but passes program name "b" as the parameter.
X executes differnt code deending on whether the passed parameter was "a" or "b".

Interesting exam question: Explain why "cd" must be a built-in (and not an external
command)?

lec # wk 10 File Attributes - Square Bracket command external or internal

photo
From: Lee dB.
Date: Tue 9th Jun, 7:50pm
Actions: 
        Login-to-reply

 

"David May" <17*1*2*[email protected]*u*e*t*u*a*e*u*a*> wrote:

> Sometimes the same executable file supports multiple commands and executes the
> one it was called with based on value of the program name (argv[0]) passed to it.
> E.g. executable file X may be linked to by "a" and "b". When you run command "a"
> the system runs command X with program name (argv[o]) set to  "a" but if you run
> command "b" the system runs X but passes program name "b" as the parameter.
> X executes differnt code deending on whether the passed parameter was "a" or "b".
> 
> Interesting exam question: Explain why "cd" must be a built-in (and not an external
> command)?

Hmmm, good mock question. I’m just testing my understanding here, but cd doesn’t strictly 
have to be a shell built-in, as long as there is some mechanism for CD to communicate with 
the shell? i.e there is no fundamental need for cd to not be external, as long as bash was 
modified to communicate somehow with the cd external?

lec # wk 10 File Attributes - Square Bracket command external or internal

photo
From: Alastair H.  O.P.
Date: Tue 9th Jun, 9:01pm
Actions: 
        Login-to-reply

 

"Christopher McDonald" <ch*i*.*c*o*a*[email protected]*a*e*u*a*> wrote:

> On my Ubuntu Linux system, the commands [ and test both exists (now) in /usr/bin, but are not links 
> to each other (and different sizes).  Interestingly  'man test'  provides the online documentation 
> for both.  On macOS /bin/[ and /bin/test  are the same binary (but still not linked ?).
> 
> On Linux, you can see all the bash builtin commands with    man bash-builtins
> on macOS with  man builtins
> 
> Included in these builtins, familiar to us, are - [, alias, cd, echo, expo, eval, exit, pwd, and 
> read.  Some of these previously existed as external commands, some *must* be internal commands.

thanks Chris, I assume you mean expr?

lec # wk 10 File Attributes - Square Bracket command external or internal

photo
From: Christopher M.
Date: Wed 10th Jun, 4:11am
Actions: 
        Login-to-reply

 

"Lee de Byl" <10*0*8*[email protected]*u*e*t*u*a*e*u*a*> wrote:

> Hmmm, good mock question. I’m just testing my understanding here, but cd doesn’t strictly 
> have to be a shell built-in, as long as there is some mechanism for CD to communicate with 
> the shell? i.e there is no fundamental need for cd to not be external, as long as bash was 
> modified to communicate somehow with the cd external?

Today, 'cd' has to be internal to the shell, so that it can change the shell (process's) environment.  
Today's there no way for one process (such as child of a shell) to change the environment of another 
process - an external 'cd' command could change *its* working directory, but not that of its parent.

Way back in v6 Unix, mid-seventies, there was a small number of external commands that could modify where 
a shell would next read from a shellscript - enabling the external 'if', 'exit', and 'goto' commands:

  https://v6sh.org

Interesting stuff, but not missed by many.

lec # wk 10 File Attributes - Square Bracket command external or internal

photo
From: Christopher M.
Date: Wed 10th Jun, 4:12am
Actions: 
        Login-to-reply

 

"Alastair Haldane" <22*6*3*[email protected]*u*e*t*u*a*e*u*a*> wrote:

> thanks Chris, I assume you mean expr?

Indeed;  just checking to see if anyone was reading it :-)

lec # wk 10 File Attributes - Square Bracket command external or internal

photo
From: Lee dB.
Date: Wed 10th Jun, 9:33am
Actions: 
        Login-to-reply

 

"Christopher McDonald" <ch*i*.*c*o*a*[email protected]*a*e*u*a*> wrote:

> "Lee de Byl" <10*0*8*[email protected]*u*e*t*u*a*e*u*a*> wrote:
> 
> > Hmmm, good mock question. I’m just testing my understanding here, but cd doesn’t strictly 
> > have to be a shell built-in, as long as there is some mechanism for CD to communicate with 
> > the shell? i.e there is no fundamental need for cd to not be external, as long as bash was 
> > modified to communicate somehow with the cd external?
> 
> Today, 'cd' has to be internal to the shell, so that it can change the shell (process's) environment.  
> Today's there no way for one process (such as child of a shell) to change the environment of another 
> process - an external 'cd' command could change *its* working directory, but not that of its parent.
> 
> Way back in v6 Unix, mid-seventies, there was a small number of external commands that could modify where 
> a shell would next read from a shellscript - enabling the external 'if', 'exit', and 'goto' commands:
> 
>   https://v6sh.org
> 
> Interesting stuff, but not missed by many.

Thanks for the historical context on Unix 6. I might have to do some reading on how the mechanism worked.

I appreciate that external commands can't change the environment of the parent shell, but I was wondering if 
there's a fundamental reason why this design was put in place? Is it just that there's no real need to do so in 
practical usage, or could it cause other problems?

It seems to me that setting environment variables and making them predictably persistent across a system seems 
to be a bit of a hassle. In your opinion, is there potentially a better way?

lec # wk 10 File Attributes - Square Bracket command external or internal

photo
From: Christopher M.
Date: Wed 10th Jun, 3:28pm
Actions: 
        Login-to-reply

 

"Lee de Byl" <10*0*8*[email protected]*u*e*t*u*a*e*u*a*> wrote:

> Thanks for the historical context on Unix 6. I might have to do some reading on how the mechanism worked.

I hadn't seen them before, but that webpage provides the source code of some of those external commands.
All in C, but they reveal how it all worked.

 
> I appreciate that external commands can't change the environment of the parent shell, but I was wondering if 
> there's a fundamental reason why this design was put in place? Is it just that there's no real need to do so in 
> practical usage, or could it cause other problems?

When one (parent) process spawns another (child) process, both continue their execution, unless one blocks to wait for the 
other.  Normally the parent waits for the child to finish - we see this as the default action in the shell, unless we 
explicitly place the child process in the background:   command &

If (any) child process *could* alter the environment of its parent, it could be a bit of a nightmare.
Imagine if you'd written a program, it's executing, and suddenly one of your child processes changes *your* current working 
directory;  suddenly you start creating files in 'random' places, or the 'local' files you wished to open are no longer 
there.


 
> It seems to me that setting environment variables and making them predictably persistent across a system seems 
> to be a bit of a hassle. In your opinion, is there potentially a better way?

It two parent+child processes do wish to communicate, there's a number of mechanisms for them to do so - such as pipes, 
same-computer networking, shared memory, first-in-first-out files.  Knowing that your child process wants to communicate 
with you is great, and workable, but knowing that *any* process you spawn could change your state without prior agreement, 
would make life very difficult for programmers.

lec # wk 10 File Attributes - Square Bracket command external or internal

photo
From: Lee dB.
Date: Wed 10th Jun, 6:39pm
Actions: 
        Login-to-reply

 

Thanks, once again Chris, for the detailed response. It's given me some food for thought.

I've recently been trying to get some environment variables to stick on my Linux machine, particularly when starting an X session 
from a TTY. There are so many possible places to do so, that it can be tricky to work out which process is inheriting its 
environment from which, especially when systemd, pam, bash, X, a display manager and the desktop environment are all spawning 
processes...

lec # wk 10 File Attributes - Square Bracket command external or internal

photo
From: Christopher M.
Date: Fri 12th Jun, 3:51am
Actions: 
        Login-to-reply

 

"Lee de Byl" <10*0*8*[email protected]*u*e*t*u*a*e*u*a*> wrote:

> I've recently been trying to get some environment variables to stick on my Linux machine, particularly when starting an X session 
> from a TTY. There are so many possible places to do so, that it can be tricky to work out which process is inheriting its 

Hi Lee,

Unsure exactly what you're trying to do, but this may help:

  https://askubuntu.com/questions/47642/how-to-start-a-gui-software-on-a-remote-linux-pc-via-ssh

lec # wk 10 File Attributes - Square Bracket command external or internal

photo
From: Lee dB.
Date: Fri 12th Jun, 10:31am
Actions: 
        Login-to-reply

 

Thanks Chris -- I think I've completely derailed this thread of conversation, so this may be a conversation for another time and place!
This Page


Program written by: [email protected]
Feedback welcome
Last modified:  3:57pm Aug 06 2020