Login or Register to Ask a Question and Join Our Community


UNIX for Dummies Questions & Answers

Why Do You Need the Explicit Pathname to Execute?

 
Thread Tools Search this Thread
Top Forums UNIX for Dummies Questions & Answers Why Do You Need the Explicit Pathname to Execute?
# 15  
Old 11-30-2012
Quote:
Originally Posted by sudon't
I was only wondering why, when you are in the same directory as a file, (not only executables), to access it, you only need its name.
The open() system call, which is used to open a file for reading/writing, supports relative paths. When the path to the file does not contain any slashes, it is designed to look in the current working directory.

The exec*() family of system calls/library functions used to execute a file do not behave in this way. Some require an absolute path. Others (the ones with a p in their name), when the path provided does not contain a slash, will search only the directories in the $PATH environment variable.

Security aside, the PATH lookup mechanism is a convenience which saves a lot of typing. Further, since all unix-like systems do not agree on exactly where every executable should be placed, $PATH lookup insulates scripts from these differences, improving portability.

If you really wanted command invocation to work the way that file opening works, simply set PATH to .. Absolute paths to commands never use PATH. Relative paths will only look in the current working directory. Such a configuration, however, if enforced from the kernel onwards, would severely break any extant unix. Boot scripts, shell profiles, software installation scripts, cronjobs, and more would all have to be rewritten.

Regards,
Alister
Last edited by Corona688; 11-30-2012 at 01:09 PM..
This User Gave Thanks to alister For This Post:
sudon't
# 16  
Old 11-30-2012
Quote:
Originally Posted by alister
The open() system call, which is used to open a file for reading/writing, supports relative paths. When the path to the file does not contain any slashes, it is designed to look in the current working directory.

The exec*() family of system calls/library functions used to execute a file do not behave in this way. Some require an absolute path. Others (the ones with a p in their name), when the path provided does not contain a slash, will search only the directories in the $PATH environment variable.

Security aside, the PATH lookup mechanism is a convenience which saves a lot of typing. Further, since all unix-like systems do not agree on exactly where every executable should be placed, $PATH lookup insulates scripts from these differences, improving portability.

If you really wanted command invocation to work the way that file opening works, simply set PATH to [icode]./icode]. Absolute paths to commands never use PATH. Relative paths will only look in the current working directory. Such a configuration, however, if enforced from the kernel onwards, would severely break any extant unix. Boot scripts, shell profiles, software installation scripts, cronjobs, and more would all have to be rewritten.

Regards,
Alister
Adding a relative directory into your PATH can have problems beyond the obvious.

Many shells cache a list of available commands they find in PATH. Put a relative directory in there, and they may not always find all available commands because they don't know the cache needs to be regenerated every time you cd. Some may even crash if you put a relative directory in PATH.
# 17  
Old 11-30-2012
Quote:
Originally Posted by Corona688
Adding a relative directory into your PATH can have problems beyond the obvious.

Many shells cache a list of available commands they find in PATH. Put a relative directory in there, and they may not always find all available commands because they don't know the cache needs to be regenerated every time you cd. Some may even crash if you put a relative directory in PATH.
I never suggested that such a thing should be done. I simply noted that with PATH set to . command lookup behaves like filename lookup (an observation which was followed by some of the disastrous consequences).

Building such a system would require auditing/rewritting all of its scripts. In the wake of such a feat, it shouldn't be too much trouble to disable the shell's caching, which in such an environment would serve no purpose.

Regards,
Alister

P.S. Corona, thanks for the icode markup fix.
Last edited by alister; 11-30-2012 at 01:58 PM..
# 18  
Old 11-30-2012
Quote:
Originally Posted by Corona688
That's a reason, but not the reason. The entire system uses PATH, not just you. This restriction gets rid of many unpredictable, unintended consequences.
OK, yes, that was very helpful. Everything that everyone was telling me is beginning to come together in my head.

Quote:
Originally Posted by alister
The open() system call, which is used to open a file for reading/writing, supports relative paths. When the path to the file does not contain any slashes, it is designed to look in the current working directory.

The exec*() family of system calls/library functions used to execute a file do not behave in this way. Some require an absolute path. Others (the ones with a p in their name), when the path provided does not contain a slash, will search only the directories in the $PATH environment variable.
Thanks, this also really helpful. But I have to ask: the ones with a 'p' in their name? I tried looking in man, but it only tells you it's a built-in. Is there a place where you can read about built-ins, system calls, or library functions?
# 19  
Old 11-30-2012
Quote:
Originally Posted by sudon't
But I have to ask: the ones with a 'p' in their name? I tried looking in man, but it only tells you it's a built-in. Is there a place where you can read about built-ins, system calls, or library functions?
On linux and BSD systems (perhaps other Unices as well), system calls are documented in section 2 and library functions in section 3 of the manual pages.

Builtins typically refer to shell functionality (echo, printf, time, cd, ...) which is often also available through standalone executables. Shell builtins should be documented in your shell's manual.

As for the exec functions with a p in their name, they are not builtins. Your man search probably returned information on the exec shell builtin. For the exec*() functions' documentation, see exec(3) - Linux manual page

Note that all of those are C library functions which wrap the execve system call. This is also the case for the *BSD implementations.

Regards,
Alister
This User Gave Thanks to alister For This Post:
sudon't
# 20  
Old 11-30-2012
Quote:
Originally Posted by sudon't
The thing that surprises me, is that bash says "command not found," when it had no trouble finding the file only a moment before.
The reason is that bash (and any other shell i know of) is bothering to even look in $PWD - unlike DOS/Windows, which did (and this way spoiled people). "bash" looks exclusively along the PATH variable - and nowhere else. Whereas most application programs and system utilities default for files to the PWD, programs are only searched along the PATH. For this, if a program is not in a directory included in PATH, you have to use a complete path. This is either something like "/some/path/to/...." or "./path" - and "." is like a system variable meaning PWD.


Quote:
Originally Posted by sudon't
If I may borrow from your example, someone who gained access to my account might look around and see the little innocuous scripts I'm writing, replace one of them with your malicious script, giving it the same name as one of mine.
True - but then the security-breach has happened already by someone gaining access to your account.

bakunin
This User Gave Thanks to bakunin For This Post:
sudon't
# 21  
Old 11-30-2012
Ok, I had to do
Code:
$ man man

to figure out how to access other sections. What an idea!
But now I know which sections to look in, which is very helpful. Thanks!
 
Login or Register to Ask a Question

Previous Thread | Next Thread

9 More Discussions You Might Find Interesting

1. IP Networking

Add explicit route

Add explicit route to 10.128.255.41/32 , gateway: 10.128.201.254 if not working, please try gateway through management port: 10.128.55.254 Just want to double confirm if this would be the correct command #route add -net 10.128.255.41/32 10.128.201.254 And if didnt work #route add... (1 Reply)
Discussion started by: Thilagarajan
1 Replies

2. Shell Programming and Scripting

SSH shell script to access FTP over explicit TLS/SSL

Hello, I use the following SSH script to upload *.jpg files via FTP: #!/usr/bin/expect set timeout -1 spawn ftp -v -i expect "" send "\r" expect "Password:" send "\r" expect "ftp>" send "mput *.jpg\r" expect "ftp>" send "quit\r" replaced with actual ftp server/account data. ... (5 Replies)
Discussion started by: mrpi007
5 Replies

3. Shell Programming and Scripting

Perl : Global symbol requires explicit package name Error while executing

I have executed the below perl script for copying the file from one server to another server using scp. #!/usr/bin/perl -w use Net::SCP::Expect; use strict; $server= "x.x.x.x"; my $source = "/mypath/mypath"; my $destination = "/home/"; print "Login...Starting scp..."; $user="admin";... (1 Reply)
Discussion started by: scriptscript
1 Replies

4. AIX

X connection to localhost:10.0 broken (explicit kill or server shutdown)

I want to run applet on AIX 6 machine. I already have setup $DISPLAY variable for putty session by selecting X11 option. I got below error for any X related commands (xclock, X, applet viewer ) X connection to localhost:10.0 broken (explicit kill or server shutdown). Please can anyone... (0 Replies)
Discussion started by: kailas.girase
0 Replies

5. Cybersecurity

IPF pass in connection to port 21 even with no explicit rule

I'm running IPF on solaris 10 bash-3.00# ipf -V #display ipf version ipf: IP Filter: v4.1.9 (592) Kernel: IP Filter: v4.1.9 Running: yes Log Flags: 0 = none set Default: pass all, Logging: available Active list: 1 Feature mask: 0x107 with the following rules bash-3.00# ipfstat -o -i... (0 Replies)
Discussion started by: h@foorsa.biz
0 Replies

6. UNIX for Dummies Questions & Answers

finding pathname for directory

Hi Could someone help me? I'm not sure how to find the full pathname of a directory. I just want to be able to specify a directory. e.g directory1/directory2/directory3/directory4/directory5 I want to be able to put in "directory5" and then i want a return of the full address. ... (3 Replies)
Discussion started by: shomila_a
3 Replies

7. UNIX for Advanced & Expert Users

connection to localhost:10.0 host broken (explicit kill or server shutdown)

Hi All, We use tomcat web server and it will get terminated with below error: connection to localhost:10.0 host broken (explicit kill or server shutdown) Please let me know how to fix this error. (5 Replies)
Discussion started by: bache_gowda
5 Replies

8. Shell Programming and Scripting

Getting pathname variables with ksh

With C Shell you can get the root, head, tail and extension of a pathname by using pathname variable modifiers. Example Script: #! /bin/csh set pathvar=/home/WSJ091305.txt echo $pathvar:r echo $pathvar:h echo $pathvar:t echo $pathvar:e The result of executing this script is: ... (7 Replies)
Discussion started by: BCarlson
7 Replies

9. UNIX for Dummies Questions & Answers

find without pathname

How can I get the results of a find back without the pathname for example if i do find ../../ -name \*.sql i dont want to see directory/directory/filename.sql I only want to see filename.sql (3 Replies)
Discussion started by: MBGPS
3 Replies
Login or Register to Ask a Question