Clyde: переводы
Bash by example / Bash в примерах
→While you might have expected myenv to print the value "xemacs", it didn't quite work, because we didn't export the EDITOR environment variable. This time, we'll get it working:
1 Хотя вы вероятно ожидали, что myenv напечатает "xemacs", это не сработало, потому что мы не экспортировали переменную окружения EDITOR. Сейчас мы это исправим:
→Hmmm... because the EDITOR environment variable was not set to anything, the C program gets a null string. Let's try setting it to a specific value:
1 Хммм... из-за того, что переменная окружения EDITOR не была установлена, программа получает пустую строку. Давайте попробуем присвоить ей специальное значение:
→Now, there will be an executable program in your directory that, when run, will print the value of the EDITOR environment variable, if any. This is what happens when I run it on my machine:
1 Так в текущей директории мы получим исполняемый файл, который после запуска напечатает значение переменной окружения EDITOR, если таковая установлена. Вот что получается, когда я запускаю его на своем компьютере:
→Save the above source into a file called myenv.c, and then compile it by issuing the command:
1 Сохраните приведенный выше код в файл с названием myenv.c и затем скомпилируйте его с помощью команды:
→Recall that we also mentioned that we can "export" variables. When we export an environment variable, it's automatically available in the environment of any subsequently-run script or executable. Shell scripts can "get to" the environment variable using that shell's built-in environment-variable support, while C programs can use the getenv() function call. Here's some example C code that you should type in and compile -- it'll allow us to understand environment variables from the perspective of C:
1 Напоминаю, что мы также упоминали, что мы можем "экспортировать" переменные. Когда мы экспортируем переменную окружения, она автоматически становится доступна в окружении любого запущенного позднее скрипта или исполняемого файла. Скрипты оболочки могут "добраться" до переменной окружения используя встроенную в оболочку поддержку переменных окружения, а программы на C могут использовать функцию getenv(). Вот пример кода на C, который вы должны ввести и скомпилировать -- это позволит нам понять переменные окружения с точки зрания C:
→As you can see, we can enclose the environment variable name in curly braces when it is not clearly separated from the surrounding text. While $myvar is faster to type and will work most of the time, ${myvar} can be parsed correctly in almost any situation. Other than that, they both do the same thing, and you will see both forms of variable expansion in the rest of this series. You'll want to remember to use the more explicit curly-brace form when your environment variable is not isolated from the surrounding text by whitespace (spaces or tabs).
0 Как вы можете видеть, мы можем заключить имя переменной окружения в фигурные скобки, когда оно четко не отделено от текста. Хотя ввести $myvar быстрее и это будет работать в большинстве случаев, ${myvar} может быть обработано правильно практически в любой ситуации. Кроме того, они делают одно и то же и вы будете видеть обе формы подстановки переменных до конца руководства. Запомните использовать более ясную форму -- ограничение фигурными скобками, когда ваша переменная окружения не изолирована от текста (пробелами или символами табуляции).
→Thirdly, while we can normally use double quotes instead of single quotes, doing so in the above example would have caused an error. Why? Because using single quotes disables a bash feature called expansion, where special characters and sequences of characters are replaced with values. For example, the "!" character is the history expansion character, which bash normally replaces with a previously-typed command. (We won't be covering history expansion in this series of articles, because it is not frequently used in bash programming. For more information on it, see the "HISTORY EXPANSION" section in the bash man page.) While this macro-like functionality can come in handy, right now we want a literal exclamation point at the end of our environment variable, rather than a macro.
1 Далее, хотя мы можем использовать двойные кавычки вместо одинарных, в предыдущем примере это привело бы к ошибке. Почему? Потому что одинарные кавычки отключают функцию bash называемую подстановкой, когда специальные символы и последовательности символов заменяются своими значениями. Например, "!" -- это символ, который bash обычно заменяет командой, напечатанной перед этим. (Мы не будем покрывать это в данных статьях, так как это редко используется при программировании в bash. Для подробной информации об этом смотрите раздел "HISTORY EXPANSION" на man-странице bash.) Хотя такая расширенная функциональность может пригодиться, сейчас нам нужен восклицательный знак в конце переменной окружения, а не расширенная функциональность.
→For extremely detailed information on how quotes should be used in bash, you may want to look at the "QUOTING" section in the bash man page. The existence of special character sequences that get "expanded" (replaced) with other values does complicate how strings are handled in bash. We will just cover the most often-used quoting functionality in this series.
1 За подробной информации о том, как должны быть использованы кавычки, вы можете обратиться в раздел "QUOTING" на man-странице bash. Существование специальных последовательностей символов, которые "подставляются" (заменяются) другими значениями усложняет обработку строк в bash. В этом руководстве мы покроем только наиболее часто используемые функции кавычек.
→We wanted this to echo "fooThis is my environment variable!bar", but it didn't work. What went wrong? In a nutshell, bash's variable expansion facility in got confused. It couldn't tell whether we wanted to expand the variable $m, $my, $myvar, $myvarbar, etc. How can we be more explicit and clearly tell bash what variable we are referring to? Try this:
1 Мы хотели вывести "fooThis is my environment variable!bar", но это не сработало. Что пошло не так? Вкратце, средство bash, подставляющее значения переменных, было сбито с толку. Данная команда не определяет хотели ли мы подставить значение переменной $m, $my, $myvar, $myvarbar и так далее. Как мы можем более четко и ясно сказать bash какую переменную мы меем в виду? Попробуйте это:
→By preceding the name of our environment variable with a $, we can cause bash to replace it with the value of myvar. In bash terminology, this is called "variable expansion". But, what if we try the following:
1 Предваряя имя нашей переменной окружения знаком $, мы заставляем bash подставить значение myvar. В терминах bash это называется "подстановка переменной". Но что, если мы попробуем следующее:
→Under bash and almost all other shells, the user can define environment variables, which are stored internally as ASCII strings. One of the handiest things about environment variables is that they are a standard part of the UNIX process model. This means that environment variables not only are exclusive to shell scripts, but can be used by standard compiled programs as well. When we "export" an environment variable under bash, any subsequent program that we run can read our setting, whether it is a shell script or not. A good example is the vipw command, which normally allows root to edit the system password file. By setting the EDITOR environment variable to the name of your favorite text editor, you can configure vipw to use it instead of vi, a handy thing if you are used to xemacs and really dislike vi.
−1 В bash и почти во всех других оболочках пользователь может определять переменные окружения, которые хранятся в виде ASCII строки. Одно из удобств переменных окружения заключается в том, что они являются стандартной частью модели процессов в UNIX. Это значит, что переменные окружения могут быть использованы не только в скриптах оболочки, но так же и в обычных программамах. Когда мы "экспортируем" переменную окружения в bash, последующие программы, которые мы запустили позже, могут прочитать нашу переменную, будь то скрипт оболочки или нет. Хорошим примером является команда vipw, которая позволяет суперпользователю редактировать системный файл паролей. Установив в переменную окружения EDITOR имя вашего любимого текстового редактора, вы можете использовать vipw вместо vi, это удобно, если вы привыкли к xemacs и не любите vi.
→#include
#include
int main(void) {
char *myenvvar=getenv("EDITOR");
printf("The editor environment variable is set to %s
",myenvvar);
}
#include
int main(void) {
char *myenvvar=getenv("EDITOR");
printf("The editor environment variable is set to %s
",myenvvar);
}
0 #include
#include
int main(void) {
char *myenvvar=getenv("EDITOR");
printf("The editor environment variable is set to %s
",myenvvar);
}
#include
int main(void) {
char *myenvvar=getenv("EDITOR");
printf("The editor environment variable is set to %s
",myenvvar);
}
→That's where this series comes in. In it, I'll show you how to actually use bash programming constructs, so that you will be able to write your own scripts. Instead of technical descriptions, I'll provide you with explanations in plain English, so that you will know not only what something does, but when you should actually use it. By the end of this three-part series, you'll be able to write your own intricate bash scripts, and be at the level where you can comfortably use bash and supplement your knowledge by reading (and understanding!) the standard bash documentation. Let's begin.
1 Вот для чего предназначено это руководство. Здесь я покажу вам как нужно программировать в bash, вы научитесь писать свои собственные скрипты. В отличии от технических описаний, я буду объяснять на простом языке так, что вы будете не только знать как что-то работает, но и когда вы должны это использовать. К концу этого руководства из трех частей вы сможете писать свои замысловатые скрипты в bash и выйдите на уровень, необходимый для комфортного использования bash и пополнения своих знаний путем чтения (и понимания!) стандартной документации bash. Давайте начнем.
→While this may be somewhat disappointing to novices, the standard bash documentation can't be all things to all people, and caters towards those already familiar with shell programming in general. There's definitely a lot of excellent technical information in the man page, but its helpfulness to beginners is limited.
1 Как это неутешительно для новичков, но стандартная документация bash не может быть одинаково полезна для всех и ориентирована прежде всего на тех, кто уже в целом знаком с программированием в командной оболочке. В man определенно много отличной технической информации, но её полезность для начинающих ограничена.
→Learning bash the wrong way can be a very confusing process. Many newbies type man bash to view the bash man page, only to be confronted with a very terse and technical description of shell functionality. Others type info bash (to view the GNU info documentation), causing either the man page to be redisplayed, or (if they are lucky) only slightly more friendly info documentation to appear.
0 Неправильное изучение bash может сильно запутать. Многие новички открывают man, чтобы прочитать руководство пользователя bash, и сталкиваются только лишь с кратким техническим описанием функций оболочки. Другие открывают info (чтобы посмотреть докумнетацию GNU) и получают ту же самую страницу man или (если повезет) только слегка упрощенную её версию.
→Not only are you already running bash, but you're actually interacting with bash on a daily basis. It's always there, so it makes sense to learn how to use it to its fullest potential. Doing so will make your bash experience more fun and productive. But why should you learn bash programming? Easy, because you already think in terms of running commands, CPing files, and piping and redirecting output. Shouldn't you learn a language that allows you to use and build upon these powerful time-saving constructs you already know how to use? Command shells unlock the potential of a UNIX system, and bash is the Linux shell. It's the high-level glue between you and the machine. Grow in your knowledge of bash, and you'll automatically increase your productivity under Linux and UNIX -- it's that simple.
1 Вы не только уже используете его, но и ежедневно взаимодействуете с bash. И это всегда так, поэтому важно узнать как использовать его потенциал полностью. Это сделает вашу работу с bash более приятной и плодотворной. Но почему вы должны освоить программирование в bash? Просто потому, что вы уже думаете о запуске команд, копировании файлов, перенаправлении потока вывода. Не должны ли вы изучить язык, позволяющий вам использовать мощные и экономящие время конструкции, которые вы уже знаете как использовать? Командные оболочки раскрывают потенциал UNIX-систем, а bash - это командная оболочка в Linux. Это связь между вами и машиной на высоком уровне. Совершенствуя ваши знания о bash, вы одновременно повысите продуктивность своей работы с Linux и UNIX -- это так просто.
→Environment variables
1 Переменные окружения
Резюме
- Пол:
- мужчина
- Родной язык:
- русский
- С нами:
-
с 12 января 2011 г.
(5758 дней)
Не является членом клуба. - Деятельность:
-
17 версий перевода
с общим рейтингом 12
Карма: 2 (оценок: 2)