linux - File execution with dot space versus dot slash -

linux - File execution with dot space versus dot slash -

i attempting work existing library of code have encountered issue. in short, execute shell script (let's phone call 1 a) first act phone call script (b). script b in current directory (a requirement of programme i'm using). software's manual makes reference bash, comments in a suggest developed in ksh. i've been operating in bash far.

inside a, line execute b simply:

. b

it uses "dot space" syntax phone call program. doesn't unusual sudo.

when phone call a without dot space syntax, i.e.:

./a

it errors saying cannot find file b. added pwd, ls, whoami, echo $shell, , echo $path lines a debug , confirmed b in fact right there, script running same $shell @ command prompt, script same user am, , script has same search path $path do. verified if do:

. b

at command line, works fine. but, if alter syntax within a to:

./b

instead, a executes successfully.

similarly, if execute a dot space syntax, both . b , ./b work.

summarizing: ./a works if a contains ./b syntax. . a works a either ./b or . b syntax.

i understand using dot space (i.e. . a) syntax executes without forking subshell, don't see how result in behavior i'm observing given file right there. there i'm missing nuances of syntax or parent/child process workspaces? magic?

update1: added info indicating script may have been developed in ksh, while i'm using bash. update2: added checking verify $path same.

update3: script says written ksh, running in bash. in response kenster's answer, found running bash -posix . b fails @ command line. indicates difference in environments between command line , script latter running bash in posix-compliant mode, whereas command line not. looking little closer, see in bash man page:

when invoked sh, bash enters posix mode after startup files read.

the shebang a indeed #!/bin/sh.

in summary, when run a without dot space syntax, it's forking own subshell, in posix-compliant mode because shebang #!/bin/sh (instead of, e.g., #!/bin/bash. critical difference between command line , script runtime environments leads a beingness unable find b.

let's start how command path works , when it's used. when run command like:

ls /tmp

the ls here doesn't contain / character, shell searches directories in command path (the value of path environment variable) file named ls. if finds one, executes file. in case of ls, it's in /bin or /usr/bin, , both of directories typically in path.

when issue command / in command word:

/bin/ls /tmp

the shell doesn't search command path. looks file /bin/ls , executes that.

running ./a illustration of running command / in name. shell doesn't search command path; looks file named ./a , executes that. "." shorthand current working directory, ./a refers file ought in current working directory. if file exists, it's run other command. example:

cd /bin ./ls

would work run /bin/ls.

running . a illustration of sourcing file. file beingness sourced must text file containing shell commands. executed current shell, without starting new process. file sourced found in same way commands found. if name of file contains /, shell reads specific file named. if name of file doesn't contain /, shell looks in command path.

. # looks using command path, might source /bin/a illustration . ./a # sources ./a

so, script tries execute . b , fails claiming b doesn't exist, though there's file named b right there in current directory. discussed above, shell have searched command path b because b didn't contain / characters. when searching command, shell doesn't automatically search current directory. searches current directory if directory part of command path.

in short, . b failing because don't have "." (current directory) in command path, , script trying source b assuming "." part of path. in opinion, bug in script. lots of people run without "." in path, , script shouldn't depend on that.

edit:

you script uses ksh, while using bash. ksh follows posix standard--actually, ksh basis posix standard--and searches command path described. bash has flag called "posix mode" controls how strictly follows posix standard. when not in posix mode--which how people utilize it--bash check current directory file sourced if doesn't find file in command path.

if run bash -posix , run . b within bash instance, should find won't work.

linux bash shell operators ksh