Есть ли разница между & ldquo;. & Rdquo; и & ldquo; источник & rdquo; в bash, в конце концов?
Я искал разницу между «.». и «исходные» встроенные команды и несколько источников (например, в этом обсуждении и справочной странице bash) показывают, что они одинаковы.
Однако, после проблемы с переменными среды, я провел тест , Я создал файл testenv.sh, который содержит:
#!/bin/bash
echo $MY_VAR
В командной строке я выполнил следующее:
> chmod +x testenv.sh
> MY_VAR=12345
> ./testenv.sh
> source testenv.sh
12345
> MY_VAR=12345 ./testenv.sh
12345
[обратите внимание, что 1-я форма вернула пустую строку ]
Итак, этот небольшой эксперимент предполагает, что в любом случае существует разница, где для команды «source» дочернее окружение наследует все переменные от родительского, где для «.» это не так.
Я что-то пропустил или это недокументированная / устаревшая функция bash ?
[GNU bash, версия 4.1.5 (1) -release (x86_64-pc-linux-gnu)]
1 ответ
Да, вы что-то упустили.
Я думаю, вы сбиваете с толку. это означает текущий каталог, как в ./testenv.sh и '.' это означает source (которая является встроенной командой). Так в случае, когда '.' означает source, это будет . ./testenv.sh. Имеете смысл?
Итак, попробуйте следующее:
MY_VAR=12345
. ./testenv.sh
-
1[F1] сообщает ему, где именно файл, без него, bash будет сначала просматривать PATH, а затем попробовать текущий каталог, если он его не найдет. Если bash запущен в режиме POSIX, и вы не укажете путь к файлу (например, ./), он будет искать только в PATH и не сможет найти файл, если текущий каталог не находится в PATH. – geirha 30 August 2012 в 13:00
-
2@geirha Да, вы правы, source (и .) на самом деле сначала проверит $ PATH, хотя на самом деле не работает сценарий в обычном смысле. Мой (бывший) комментарий был неправильным. – Eliah Kagan 30 August 2012 в 14:31
-
3Короткая и точка +1 – David Morales 25 August 2016 в 21:35