0

I'm looking at 2 files that were written by someone else, and I'm not understanding the syntax. foo.sh calls bar.sh

foo.sh

#!/bin/bash
. /ABSOLUTE/PATH/TO/FILE/bar.sh hello

bar.sh

echo bar: $1 $2

The stdout from running foo.sh is bar: hello

The primary confusion is why does the line . /ABSOLUTE/PATH/TO/FILE/bar.sh hello start with a . (Note the space, this is not a relative path, but an absolute path). It seems I can call bar.sh with or without the . and it seems to work (Note there is no #!/bin/bash in bar.sh)

My secondary confusion is that bar.sh seems to be referencing 2 parameters $1 and $2, but seems like only one parameter is being passed in. This is code that I believe is running, and relies on $2 being valid (but I don't know what the value is).

Gilles Quénot
  • 173,512
  • 41
  • 224
  • 223
nanotek
  • 2,959
  • 15
  • 25
  • 1
    Take a look at the bash source commando – 0stone0 Apr 14 '23 at 16:03
  • Wow, I did not see that coming. If you want to put your comment into an answer I'll accept it – nanotek Apr 14 '23 at 16:06
  • I don't think they are duplicates... but ok – nanotek Apr 14 '23 at 16:09
  • Read the ressource, there's all what you need to know. If not, convince me to retract the closed question – Gilles Quénot Apr 14 '23 at 16:09
  • Well they are different questions. If you are just searching online for 'why does a bash line start with a `.` you aren't going to come across that other question. The other question assumes there is some connection between source and `.`, where mine, I had no idea. I thought it was doing something different like if you start a line with a `@`. I agree the other resource answers my question, but if you are searching for this problem you'd never find that answer (I didn't/wouldn't) – nanotek Apr 14 '23 at 16:15
  • 2
    Letting people know that something is duplicate even though that's not obvious at a glance is the whole **point** of flagging things as duplicates in our knowledgebase, to let readers know they're the same question even if they don't look like it so we can have a single most canonical set of answers without clogging up with duplicates. It doesn't mean the question was bad or worthless, but it means we don't need two different answer sets, and it adds extra search terms that point to the same canonical answer. – Charles Duffy Apr 14 '23 at 16:21
  • 1
    To put it differently, a "good" duplicate is one that adds new search terms pointing to the same solution set, whereas a "bad" duplicate is one where the person asking just didn't search. We're not saying this is a bad duplicate; we're just saying _that it's a duplicate_. The potential for something to be a good duplicate is why questions can still get upvoted after being closed as duplicate (unlike most other close reasons), and if they _are_ upvoted or get a high view count (meaning it's actually meeting the goal of coming up in search results) they don't get auto-deleted. – Charles Duffy Apr 14 '23 at 16:23
  • 1
    (btw, `$2` is quite certainly empty in your use case; to see definitively, you can do something like `{ echo "$# arguments:"; printf ' - %q\n' "$@"; } >&2`) – Charles Duffy Apr 14 '23 at 17:28

0 Answers0