להוציא לפועל מחרוזת
רמת קושי: #beginners

בעבר דיברנו על כלים שבאש מספקת לנו כדי לפרסר תוכן של משתנים בעת הקריאה אליהם היום נפגוש את bash Parameter transformation

להלן המחרוזת שלנו, כמו שרואים היא מכילה תווי בקרה, תווי שליטה בשורת הפקודה (Controlling the Prompt) ומחרוזת עטופה בגרש

$ mystring="\narrow\nice\n\d\n\h\n'qoute'"

בעת שאנו משתמשים במחרוזת, באש מאפשרת לקחת את התוכן של המשתנה ולבחור באיזו וריאציה להציג את המחרוזת.

אופרטור Q יציג את הטקסט ויעטוף אותו בגרש בודד כך שיוכל לשמש כקלט לכלי אחר, כולל החרגה של גרש בודד בטקסט עצמו

$ echo "${mystring@Q}"
'\narrow\nice\n\d\n\h\n'\''qoute'\'''

אופרטור E יציג את התוכן כולל תווי בקרה שנמצאים בטקסט

$ echo "${mystring@E}"

arrow
ice
\d
\h
'qoute'

אופרטור P יציג גם את תווי השליטה של שורת הפקודה, במקרה שלנו הם \d ו \h

player@playground:~$ echo "${mystring@P}"

arrow
ice
Sat Aug 01
playground
'qoute'


דבר נחמד בהקשר הזה, בעת שימוש בסקריפט ניתן להעביר את כל הפרמטרים על ידי * או @ וכל פרמטר יעבור דרך האורפטור והטקסט יחולל בהתאם

$ cat myfile.sh
echo "${*@P}"

$ bash myfile.sh "\d" "\h"
Sat Aug 01 playground


#parameter_transformation
#variable
#string

@bash_tips

פקודת השמה ו export

לא מעט סקריפטים שנמצא נראה שמכריזים על משתנים במספר דרכים, אחת בצורה מפורשת עם export והשניה פשוט על ידי פקודת השמה של ערך למשתנה

myvar="some text here"
export my_another_var="another text here"

בשני המקרים המשתנה שלנו יהיה קיים אך ורק לסשן הנוכחי ולאחר מכן יתנדף ולא יהיה קיים יותר.
מה שמוביל אותנו לשאלה לשם מה צריך את הפקודה export אם שני הפעולות עושות את אותה עבודה?

העניין עם פקודת export הוא כזה, כשיוצרים משתנה רגיל הוא אכן נוצר לסשן הקיים אבל הוא רלוונטי אך ורק לקוד של הפרוסס הנוכחי שרץ

/tmp/tests $ myvar="some text here"
/tmp/tests $ bash echo_myvar.sh

/tmp/tests $

בשלב הראשון אני מכריז על משתנה בסשן בשלב השני אני מריץ סקריפט, הסקריפט רץ תחת הסשן שלי אבל כ sub process.

מצד שני אם נשתמש ב export

/tmp/tests $ export myvar="another text here"
/tmp/tests $ bash echo_myvar.sh
another text here
/tmp/tests $

שימוש ב export יורש את כל סביבת הסשן הנוכחי ומעביר אותו אל תת התהליך. כמובן שלאחר שהמשתנה הוכרז עם export כל פקודת השמה של ערך למשתנה בתהליך הראשי ישפיע על התוכן בתתי התהליכים.

#export
#variable
#env_variable
#session
#sub_process

@bash_tips

לטעון סביבה
רמת קושי: #advanced

קובץ שמוכר בעולם ה ops הוא .env מדובר על קובץ שבגדול מכיל רשימה של משתני סביבה בהם הסביבה מאותחלת, מספר כלים כדוגמת docker-compose מכירים בקובץ ויודעים לטעון אותו לבד, מה קורה כשאנו רוצים לטעון קובץ .env ישירות לטרמינל?

דוגמה לקובץ .env

$ cat .env
APP_NAME=mytest
DEPLOYMENT_MODE=true
BUNDLE=test
...

מחשבה ראשונה זה לעשות source לקובץ ולטעון אותו, העניין הוא שהכרזת משתנים בלי הפקודה export תטען את המשתנים לסשן של הטרמינל, כל סקריפט שנריץ מאותו הסשן לא יקבל את המשתנים שבקובץ כי הוא רץ בסשן משל עצמו (דברנו על זה מעט בעבר).

נוכל לראות זאת בדוגמה שלהלן

$ source .env

$ cat test.sh
#!/bin/bash
declare -p APP_NAME DEPLOYMENT_MODE BUNDLE

$ bash test.sh
test.sh: line 2: declare: APP_NAME: not found
test.sh: line 2: declare: DEPLOYMENT_MODE: not found
test.sh: line 2: declare: BUNDLE: not found


להלן 2 דרכים מעניינות לפתרון
פתרון אפשרי, export

export $(grep -v '^#' .env)

מה שקורה כאן הוא שפקודת export יודעת להגדיר מספר משתנים בו זמנית, grep מחריג כל שורה שהיא הערה וכך טוען רק את המשתנים, אפשר כמובן לשפר את החלק האחרון אבל הרעיון במקומו.


פתרון אפשרי נוסף allexport

set -a
source .env
set +a

בגדול מדובר על הפעלה של flag allexport, האופציה הזאת מעבירה לexport את רצף המשתנים ובעצם מאפשרת לפקודת source לטעון את כל המידע שבקובץ, אנו מכבים את האופציה לאחר שטענו את הסביבה.

בכדי לראות שהמשתנים שלנו אכן נטענו לסביבה ניתן לבדוק זאת על ידי פקודת env שמציגה בעצם את כל המשתנים של הסביבה בה אנו עובדים.


#env
#export
#source
#variable
#env_variable
#session

@bash_tips