ToCode

# איך לבלבל את החברים עם קובץ usercustomize.py לא רבים יודעים אבל מספר קבצים מסתוריים במערכת הקבצים של משתמשי פייתון. אחד מהם נקרא usercustomize.py. אני לא בטוח מה היתה המטרה המקורית של הפיצ'ר, אבל המצב היום הוא שאם תשימו קובץ כזה בתוך תיקיית site-packages על המחשב שלכם, אז כל פעם שתפעילו סקריפט פייתון המפרש יטען קודם כל את הקובץ usercustomize.py ורק אחר כך יעבור להפעיל את הסקריפט. (וכן זה עובד אפילו עם ה REPL9). בואו ננסה את זה. קודם כל צריך לגלות איפה נמצאת ספריית site-packages בהתקנת הפייתון שלכם. אולי אתם כבר יודעים, ובכל מקרה אם לא תוכלו להפעיל את הפקודה:

python -c "import site; print(site.getsitepackages())"

אצלי היא הדפיסה:

['/Users/ynonp/.pyenv/versions/3.11.1/lib/python3.11/site-packages']

אני יוצר קובץ חדש בתוך התיקיה בשם usercustomize.py, ובתוכו כותב את התוכן הבא:

print("I will NOT go away. I do NOT wish to go!")

בואו ננסה את זה. אני מפעיל REPL ומקבל את הפלט:

I will NOT go away. I do NOT wish to go!
Python 3.11.1 (main, Apr  6 2023, 09:09:27) [Clang 14.0.0 (clang-1400.0.29.202)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>

אני מפעיל שרת HTTP ומקבל:

$ python -m http.server 8000

I will NOT go away. I do NOT wish to go!
Serving HTTP on :: port 8000 (http://[::]:8000/) ...

וכמובן גם כל תוכנית פייתון שאריץ תדפיס את אותה הודעה. אז למה זה טוב? (חוץ מלבלבל את החברים). הנה כמה רעיונות: 1. אפשר ליצור במקום אחד הגדרות log טובות יותר, ואז כל הסקריפטים ישתמשו בהגדרות הלוג שלכם גם בלי לעשות import מיוחד. 2. אפשר להוסיף עוד ספריות ל PYTHONPATH כדי לטעון מהן מודולים. 3. אפשר לתעד כל הפעלה של פייתון או למנוע הפעלות מסוימות (לדוגמה אפשר להוסיף sys.exit בתוך הקובץ אם לא רוצים לאפשר הפעלה מסוימת). הבעיה המרכזית עם שימוש בקובץ הזה למטרות אמיתיות היא שמעטים מכירים אותו, ולכן סיכוי טוב שמי שמתחזק את הקוד שלכם ילך לאיבוד ולא ימצא למה פונקציונאליות מסוימת קורית. יש לכם עוד רעיונות טובים לשימוש ב usercustomize.py? נתקלתם ב Use Cases מעניינים איתו? ספרו לי בתגובות.

# החיים באי וודאות יש שריר כזה שעוזר לחיות עם אי וודאות, והחיים בעידן האינטרנט והסלולר לא נותנים לו הרבה הזדמנויות להתחזק. אם שואלים אותך שאלה קשה במיוחד בראיון עבודה, כמה ארוך יהיה הדיאלוג לפני שתגיע הבקשה לרמז? כמה זמן תתנו לעצמכם לעבוד על פרויקט צד לפני שתוותרו כי זה לא בטוח יצליח? כמה זמן תצליחו להשקיע בלימוד טכנולוגיה לפני שתצטרכו הבטחה שאכן טכנולוגיה זו תתן ערך? הצורך בוודאות הוא הסיבה שהרבה יותר קל לנו ללמוד טכנולוגיה כשהבוס מבקש מאשר בלימוד עצמי בבית. הרבה יותר קל לנו לעבוד בחברת סטארט-אפ מאשר על סטארט-אפ משלנו. אבל היכולת לחיות עם אי וודאות היא הכרחית אם החלום שלנו הוא לפתור בעיות מעניינות (כאלה ש Chat GPT לא יודע לפתור). הנה כמה רעיונות איך לאמן את שריר החיים עם אי הוודאות, בהתחלה על דברים לא חשובים ולאט לאט גם על דברים יותר חשובים- 1. נסו לראות סידרת טלוויזיה באנגלית בלי כתוביות (או אם האנגלית שלכם טובה בשפה אחרת שאתם לא 100% בה). המטרה היא ללמוד ליהנות גם בלי להבין את כל הדיאלוג. 2. נסו לקחת חידת היגיון קשה ופשוט לחשוב עליה רבע שעה, ואז להניח אותה בצד ולהמשיך לחשוב עליה שוב מחר. זה בסדר גם אם לא תפתרו אפילו במשך כמה שבועות. 3. אתרים כמו פרויקט אוילר או Advent Of Code כוללים חידות תכנותיות רבות. חפשו שם חידה קשה שאתם לא מצליחים לפתור ביום אחד, ונסו להקדיש לה קצת זמן כל יום במשך שבוע או כמה שייקח. 4. נסו לבנות פרויקט צד ולהביא אותו לרמה של מוצר שאתם יכולים למכור. לא משנה מה הפרויקט. הריקוד כאן הוא בין שני קצוות, וצריך להיזהר לא להתקרב מדי לאף אחד מהם: קצה אחד הוא חוסר אכפתיות מהתוצאה וקצה שני הוא הצורך למצוא וודאות ולשכנע את עצמכם שבסוף זה יצליח. אנחנו רוצים להתאמן בדיוק על האמצע, על להשקיע הכי הרבה שאפשר בלי לדעת מה תהיה התוצאה.

# השוואה סובייקטיבית לגמרי בין neo4j ל datomic השבוע התבשרנו שדטומיק, או יותר נכון nubank, החברה שמחזיקה ב datomic, החליטו לבטל את כל עסקי הרישיון המסחרי של דטומיק ולהפיץ גם את גירסת הפרו בחינם. כדי לחגוג את האירוע הנה השוואה קצרה וסובייקטיבית לגמרי שלי בין שני בסיסי נתוניים גרפיים שאהבתי במיוחד - Datomic מול neo4j. ## דטומיק דטומיק הוא בסיס נתונים שכתוב ב Clojure ומקדש את עיקרון הפשטות. יש לו מבנה פשוט ואפשר בקלות לראות איך כל פעולה תתבצע בתוך מבנה זה. אלה עקרונות העבודה המרכזיים של דטומיק: 1. המידע מאוחסן בתור Tuples של: "יישות", "מאפיין", "ערך", "מתי נקבע", "האם נמחק". כל בסיס הנתונים הוא פשוט אוסף של Tuples כאלה. 2. כל תהליך שעובד מול בסיס הנתונים מקבל עותק מלא של בסיס הנתונים נכון לרגע מסוים. 3. בסיס הנתונים עובד במתכונת "הוספה בלבד". שורה שנכתבה לעולם לא תימחק ותמיד אפשר להסתכל על נתונים היסטוריים. 4. כל השאילתות והחיפושים (קריאות) מבוצעים בזיכרון של האפליקציה, שקיבלה עותק מלא של כל בסיס הנתונים נכון לרגע מסוים. לכן יצירת דוחות מורכבים לא מעמיסה על בסיס הנתונים. 5. כתיבות מבוצעות רק מתהליך בסיס הנתונים עצמו, שפועל ב Single Thread ולכן אין כתיבה במקביל. 6. בשביל טרנזאקציות אנחנו שותלים קוד בתוך תהליך הכתיבה לבסיס הנתונים. בגלל שהכתיבה היא תמיד סדרתית קוד שרץ בתוך התהליך שכותב תמיד ירוץ לבד. דטומיק נכתב על ידי חברת Cognitect שהיא גם החברה שפיתחה את שפת Clojure. החברה בבעלות Nubank ולכן בסיס הנתונים מופץ בחינם לגמרי אבל אינו בקוד פתוח. כתבתי על עבודה עם דטומיק כאן וכאן. ## נאו פור ג'יי בסיס הנתונים neo4j הוא בסיס הנתונים הגרפי בקוד פתוח הנפוץ בעולם. הוא כתוב ב Java ועובד הרבה יותר כמו בסיס נתונים מסורתי, רק שהמידע מאורגן בצמתים וקשתות. אלה מספר רעיונות מרכזיים לגביו: 1. בסיס הנתונים רץ כתהליך נפרד והתקשורת איתו מבוצעת ב HTTP או בפרוטוקול בינארי שלהם שנקרא bolt. 2. בסיס הנתונים מדבר במונחים גרפיים: יש צמתים וקשתות, אנחנו יכולים להגדיר מאפיינים על הצמתים או על הקשתות ואפשר להוסיף תוויות גם לצמתים וגם לקשתות. תוויות עוזרות לנו למצוא מידע בשאילתות. 3. אפשר להפעיל את neo4j בקלאסטר והוא תומך ב Horizontal Scaling. 4. אנחנו יכולים ליצור אינדקסים כדי לשפר ביצועים של שליפות, ויש תורה שלמה סביב ארגון המידע כדי שהשליפות יעבדו כמו שצריך. כתבתי על שאילתות ב neo4j כאן. ## השוואה סובייקטיבית לגמרי אחרי עבודה גם עם neo4j וגם עם datomic בפרויקטים שונים, אלה הנקודות המרכזיות שאהבתי או לא אהבתי בכל אחד מהם: 1. לכל בסיס נתונים שפת שאילתות משלו. ב neo4j זו Cypher וב datomic זו datalog. לי Cypher היתה קצת יותר קלה. 2. אהבתי מאוד את ה Immutability של Datomic והעובדה שמידע נשמר לנצח. מימוש של זה ב Neo4j דורש עבודה בצד האפליקציה (כמו בבסיס נתונים רלציוני רגיל) ולכן ברוב המערכת לא נשקיע בזה, רק עבור מידע מאוד ספציפי שצריך להישמר לנצח. 3. כלי העבודה למפתחים סביב Neo4j הרבה הרבה יותר נוחים ממה שיש בעולם של Datomic, ובנוסף התיעוד של neo4j והקורסים הקיימים אצלם באתר הופכים את הכניסה אליו להרבה יותר קלה בהשוואה לדטומיק. 4. אומנם אפשר לתשאל את Datomic מכל שפת תכנות, אבל אנחנו מפסידים הרבה מהיתרונות שלו אם נעבוד מולו משפה שאינה ב JVM, כי רק שפות ב JVM מקבלות את כל העותק של בסיס הנתונים לזיכרון. 5. ב neo4j אפשר לשמור מידע על הקשתות. ב Datomic צריך לבנות צומת שיחבר בין שני צמתים כי רק צמתים יכולים לשמור מידע. שורה תחתונה - Datomic הוא בסיס נתונים הרבה יותר פשוט. הגישה שלהם שמידע רק מתווסף ושכל תוספת מידע מתועדת בלוג מסודר מאוד עוזרת כשצריך לזהות מה קרה או למה משהו קרה. לעומתו neo4j כולל שפת שאילתות הרבה יותר מתוחכמת שמאפשרת לשלב בין שינויים לשליפת מידע באותה שאילתה, מגיע עם כלי פיתוח הרבה יותר מתקדמים ופשוט הרבה יותר קל להבנה, התקנה ותחילת עבודה. אם אתם מחפשים בסיס נתונים גרפי שניהם יתנו תוצאות טובות. אלה מכם שכבר מגיעים מהעולם של Clojure או Java, או שצריכים את שמירת המידע הנצחית של דטומיק יהנו ממנו מאוד. אלה שמעדיפים התקנה קלה ובסיס נתונים פופולרי שפשוט עובד יהנו יותר מ neo4j.

# סיבה ותוצאה באמצע ריצת בוקר, בעודי כואב ומתנשף, ראיתי לפניי את הבחורה הספורטיבית מהשכונה. ההיא שהכל נראה אצלה כל כך קל. שיכולה לעשות מרתון בהליכה ועדיין להגיע ראשונה. ורציתי לשאול אותה - למה את עושה את זה לעצמך? את הרי כבר כל כך ספורטיבית. בשביל מה את צריכה לצאת שוב לרוץ? למה לסבול ככה? אומנם עד שגמרתי את המחשבה היא היתה כבר קילומטרים לפניי, אבל את התשובה שלה קלטתי מיד: "זה הפוך חבוב... אני ספורטיבית ולכן אני רצה. זה מה שאנשים ספורטיביים עושים". וברגע הכל התחבר. המטרה של שינוי היא לא התוצאה, אלא להבין איך לאהוב את הדרך.

# איפה להשקיע את זמן הלימוד שלי? נצייר מערכת צירים, ציר ה x מייצג "פשטות" של ספריה וציר ה y מייצג כמה בעיות היא מסוגלת לפתור בקלות. (אין לי באמת דרך קלה להוסיף ציורים לפוסטים כאן, אז אני משאיר את הציור בדמיון). שני הצירים מחלקים את העולם ל-4 ריבועים: 1. בצד ימין למעלה אני מוצא כלים עם עיקרון הפעלה מרכזי שפותרים בעיות גדולות או הרבה בעיות, אבל אם הבנת כמה עקרונות פשוטים קל להשתמש בהם. (גיט יהיה כאן דוגמה טובה, וגם דוקר). 2. בצד ימין למטה קל לי למצוא הרבה כלים קטנים, שקל מאוד להבין אותם וכל אחד מהם עושה דבר אחד קטן כמו שצריך (לדוגמה כל הכלים של יוניקס). 3. בצד שמאל למעלה אני מוצא ספריות ופריימוורקים עשירים שפותרים את כל הבעיות של העולם אבל קשה מאוד ללמוד אותם (אני מסתכל עליכם ריילס וקוברנטיס). 4. ובצד שמאל למטה אני מוצא ספריות ופריימוורקים מסובכים שמנסים לפתור את כל הבעיות של העולם אבל כושלים (היוש אנגולר1). עכשיו בחזרה לשאלה מהכותרת, איפה להשקיע את זמן הלימוד שלי? השקעה בריבוע 1 תתן את התוצאות הטובות ביותר, כי בתמורה למספר קטן של עקרונות שהצלחתי להבין אני מקבל את הערך הגדול ביותר. לימוד כלים קטנים מריבוע 2 יעזור לשפר את הפרודוקטיביות בצעדים קטנים ומועיל לאלה שאוהבים לראות תוצאות מהר. לימוד הכלים בריבוע מספר 3 לוקח נצח, אבל אחרי שלמדתם אחד הוא יעזור לכם כמעט בכל מערכת וריבוע 4 פשוט יבזבז לכם את הזמן כמעט בלי תמורה.

# חיפוש טוב יותר דרך אחת לחשוב על מנועי הבינה המלאכותית היא בתור מנועי חיפוש טובים יותר: במקום רק לחפש את המידע הקיים, הם מצליחים לסדר מחדש את המילים כדי להבליט את הדבר שאני מחפש בצורה שרלוונטית עבורי. ןעכשיו קל לראות למה ChatGPT לעולם לא יחליף מתכנתים אנושיים, ולמה אנחנו עדיין צריכים להבין איך למצוא מעגל ברשימה מקושרת או איך בנוי רדיס. מנוע חיפוש, או אפילו צ'ט בינה מלאכותית, מוצאים לנו תשובות. אין להם (עדיין) יכולת להבין את התשובות, גם אם לפעמים המשחקים שלהם עם מילים נותנים הרגשה כאילו כן. יותר חשוב - אין להם יכולת לעצור רגע כדי להבין אם הם בכלל מבררים את התשובה לשאלה הנכונה. פיתרונות יצירתיים, הבנה לעומק של הבעיה, היכרות עם עולם התוכן ועם עולמות תוכן מקבילים, בחירה בין חלופות בצורה שתתאים לפרויקט שלי - כל הדברים שאנחנו מעריכים במתכנתים אנושיים, לא קיימים ולעולם לא יהיו חלק ממנוע חיפוש. המשימה שלנו: להמשיך לשפר את אותן מיומנויות שאיתן בנינו את ה ChatGPT וחבריו.

# איך לא לייצר סיסמה אקראית ביקשתי מ Chat GPT לכתוב פונקציית פייתון שמחזירה סיסמה אקראית מתוך אורך ורשימה של תווים בסיסמה. זאת היתה התוצאה:

import random

def generate_password(length, symbols):
    password = ''
    for i in range(length):
        password += random.choice(symbols)
    return password

בפרומפט הבא ביקשתי ממנו לכתוב גירסה מאובטחת של אותו הקוד, וקיבלתי את זה:

import string
import random

def generate_password(length):
    chars = string.ascii_letters + string.digits + string.punctuation
    while True:
        password = ''.join(random.choice(chars) for _ in range(length))
        if (any(c.islower() for c in password)
            and any(c.isupper() for c in password)
            and any(c.isdigit() for c in password)
            and any(c in string.punctuation for c in password)):
            return password

אז נכון גם הרבה מתכנתים אנושיים שאני מכיר היו משתמשים ב random.choice במקום ב os.urandom בלי לשים לב, ואולי גם אתם כתבתם קוד כזה בעבר. בכל מקרה אלה כמה סיבות בגללן אני משתדל לא לכתוב כך, גם במערכות שאינן קריטיות לאבטחה של אף אחד: 1. קוד מידבק - כש Chat GPT כותב קוד, או כשקטע קוד מופיע ב Stack Overflow, אנשים נוטים לקחת אותו כמו שהוא. התופעה אפילו יותר חמורה בתוך הארגון. כשאני כותב באיזשהו מקום במערכת קוד לא מאובטח, מישהו הולך להעתיק אותו לעוד מקומות, ואין לי שליטה לאן הקוד הזה יגיע בסוף. 2. הרגלים מדבקים - כשאני מתרגל להשתמש בפונקציות לא מאובטחות כדי לפתור בעיות, אני עלול להשתמש בהן בלי לשים לב גם כשהבעיה כן צריכה פיתרון יותר מאובטח. מצד שני כשאני מתרגל להשתמש בגישה המאובטחת בכל מצב, יהיה לי יותר קל להמשיך להשתמש בה גם במצבים שצריכים פיתרון מאובטח. 3. מודעות יוצרת ידע - כשאני מבין את החשיבות של פיתרונות מאובטחים אני מחפש יותר מידע על אבטחת מידע, וכך מייצר מעגל קסמים שיגרום לי לאט לאט לכתוב קוד יותר מאובטח. 4. קוד נכון מאפשר כלים אוטומטיים - קיימים כלי ניתוח אוטומטיים היכולים לזהות חולשות בקוד. כשאני מקפיד להשתמש בכלים מאובטחים בכל המערכת, יהיה לי יותר קל לשלב את אותם כלים. כשהקוד שלי מלא בקוד לא מאובטח (גם אם בהקשרים לא קריטיים) אותם כלים פשוט יזרקו יותר מדי False Positives ויהיה קשה למצוא את הבעיות האמיתיות בקוד. שורה תחתונה ובשביל העתיד, זו גירסה של הפונקציה שלא קיבלתי מ Chat GPT שמשתמשת ב os.urandom כדי לבחור סמלים לסיסמה בסדר אקראי ממש:

import os

def make_random_password(length=12, symbols='abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789@$^_+&'):
    password = []
    for i in map(lambda x: int(len(symbols)*x/255.0), os.urandom(length)):
        password.append(symbols[i])
    return ''.join(password)

# הטעות שכולם עושים "שתפו את הקוד" אנשים אומרים, "השתתפו בפרויקט קוד פתוח" הם ממליצים, ציידי הראשים יסתכלו לך בגיטהאב וישתכנעו שיש פה ראש ששווה לצוד. אז הלכת לקודד איזה ספריית קוד פתוח שתשנה את העולם, וכמובן שאחרי שלושה חודשים יש שם בקושי שניים וחצי משתמשים. וניסית לתרום קוד לפרויקט קוד פתוח קיים, רק בשביל לגלות שהתרומה שלך כל הזמן מקבלת ריג'קטים או שהתקבלה והפכה לטיפה בים של תרומות אחרות. ואולי אפילו הצלחת להתמיד בזה חודש, שלושה חודשים, שנה. אבל ציידי הראשים עדיין לא מתקשרים. אפילו לא איזה הודעה בלינקדאין. נו, אם כל כך הרבה זמן אני בגיטהאב ועדיין לא באו לצוד אותי - אולי השיטה הזאת לא עובדת? אולי היא לא בשבילי? אולי הגיע הזמן להפסיק? וזו הטעות הגדולה שכולם עושים. לוקח שנים לייצר את השינוי שיגרום לעולם לשים לב אליך. לוקח שנים לייצר פרויקט מספיק טוב כדי שאנשים ירצו להשתמש בו או לשתף אותו. לוקח שנים לייצר פרופיל גיטהאב מספיק מרשים, או תיק עבודות מספיק מרשים, ולצבור את כל הניסיון הדרוש כדי באמת להתקבל לכל עבודה. אם ההתמדה שלנו בעשייה תלויה בתוצאות לא נצליח ליצור את האפקט, כי התוצאות מגיעות רק אחרי הרבה מאוד השקעה. הדרך להגיע לשם, כמו בכל שינוי גדול בחיים, היא להסתכל על השינוי ועל הבן אדם שאנחנו רוצים להיות הרבה לפני שמסתכלים על התוצאות. כשנצליח להפוך את פרויקט הקוד הפתוח שבחרנו לחלק משמעותי מהחיים שלנו, כשנצליח לתרום קוד בלי לחשוב על מי שמסתכל ומה התוצאה, רק אז יהיה לנו את הכח להתמיד לאורך שנים וגם להגיע בסוף לתוצאות.

# מתי לחתוך בניסוי מפורסם של דן אריאלי הוא ביקש מאנשים בקבוצה אחת לבנות משהו מלגו ואז מפעיל הניסוי פירק את היצירה וביקש מהמשתתפים לבנות מאותם חלקים יצירה חדשה. לקבוצה השניה היתה משימה דומה, רק שבמקום לפרק את היצירות שהם בנו מפעילי הניסוי נתנו להם כל הזמן חלקי לגו חדשים, וכך הם ראו את כל היצירות שהם בנו לאורך הניסוי מצטברות על המדף. לא נופתע לגלות שהקבוצה הראשונה בנתה בממוצע פחות יצירות. מאוד קשה לבנות דברים שאתה יודע שאף אחד לא ישתמש בהם, ועוד רגע הם יפורקו. בעולם האמיתי של תכנות המצב יכול להיות הרבה יותר גרוע. בעבודה על פרויקט שאין לו משתמשים אנחנו מגלים ש- 1. בלי משתמשים אין עומס על המערכת, ולכן הקוד שכתבנו לא יודע להתמודד עם עומסים (כי הוא אף פעם לא היה צריך). 2. כשאין משתמשים לא צריך להפיץ להם את התוכנה, ולכן אנחנו נשארים עם קוד שבור שעובד רק על המכונה שלי. 3. כשאין משתמשים אין בעיות אבטחת מידע, כי אף אחד לא מנסה לשבור את הקוד, מה שמשאיר אותנו עם חולשות אבטחה פשוטות שלא התגלו. 4. בלי משתמשים אין מי שיכעס כשהפיצ'רים שאנחנו כותבים לא עובדים, מה שמשאיר אותנו עם יותר באגים במערכת. ואולי הכי גרוע זה כשהמתכנתים הטובים יעזבו את הפרויקט כדי לעבוד על פרויקטים יותר מעניינים, ואיתם מתדרדרת גם תרבות העבודה. בטווח הרחוק פרויקטים שהם Dead End רק יפגעו בקריירה שלנו, ירחיקו אותנו מהעשייה ומכתיבת קוד ברמה שאנחנו צריכים בשביל להתקדם. הפרויקט מת? זה הזמן להיפרד ולהמשיך הלאה.

# טיפ יוניקס: פיצול קלט בעזרת הפקודה split הפקודה ifconfig (או בגירסתה העדכנית יותר ip a) מציגה רשימה של כל כתובות ה ip על המכונה. זה חלק מהפלט לדוגמה:

utun6: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
        inet6 fe80::4b03:c5a9:d358:bb3a%utun6 prefixlen 64 scopeid 0x17
        nd6 options=201<PERFORMNUD,DAD>
vmenet0: flags=8b63<UP,BROADCAST,SMART,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
        ether be:50:b2:b2:bc:7b
        media: autoselect
        status: active
bridge100: flags=8a63<UP,BROADCAST,SMART,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
        options=3<RXCSUM,TXCSUM>
        ether 52:ed:3c:d3:64:64
        inet 192.168.64.1 netmask 0xffffff00 broadcast 192.168.64.255
        inet6 fe80::50ed:3cff:fed3:6464%bridge100 prefixlen 64 scopeid 0x10
        inet6 fd5e:dcce:7fd0:a7fb:10c8:64d2:15b:ca05 prefixlen 64 autoconf secured
        Configuration:
                id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
                maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
                root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
                ipfilter disabled flags 0x0
        member: vmenet0 flags=3<LEARNING,DISCOVER>
                ifmaxaddr 0 port 15 priority 0 path cost 0
        nd6 options=201<PERFORMNUD,DAD>
        media: autoselect
        status: active

הפקודה split ביוניקס יכולה לעזור לנו לפצל קלט מסוג זה, או קלטים דומים, למספר קבצים ובקלות. בשביל הדוגמה נשים לב שכל "בלוק" מתחיל בשם של ממשק רשת, אחריו נקודותיים ואז כל מיני פרמטרים של אותו ממשק במספר שורות, עד הממשק הבא. אני רוצה לפצל את הטקסט הזה לקבצים כך שנתונים על כל ממשק רשת יישמרו בקובץ נפרד ששמו כשם ממשק הרשת. ## פיתרון: הפקודה split פקודת split של יוניקס היא חלק מ core utils. היא מקבלת קובץ קלט ומייצרת ממנו קבצים אחרים במספור אוטומטי לפי פרמטרי חלוקה שנבחר. היא יכולה לפצל קלט כל n שורות, כל n בתים או במקרה שלנו כל פעם שנתקלים בתבנית מסוימת. השורה הבאה יוצרת קובץ לכל ממשק רשת מ ifconfig:

$ /sbin/ifconfig|split -p '^[a-z]'

הקבצים שנוצרו נקראים xaa, xab, xac וכך הלאה - קובץ לכל התקן רשת. עכשיו נשאר רק להריץ לולאת for פשוטה עדיין מתוך bash כדי להתאים את השמות:

$ for f in x??; do mv $f $(head -1 $f | egrep -o '^[a-z0-9]+'); done

והתוצאה - לכל ממשק רשת מ ifconfig נוצר קובץ ששמו הוא כשם ממשק הרשת, והתוכן הוא כל בלוק המידע מ ifconfig על אותו ממשק.