לינוקס כללי

מה מיוחד בלינוקס?

לינוקס היא מערכת Unix, כלומר כזו שגם עושה multitasking וגם מיועדת ל-multiuser באמצעות הרשאות וקבוצות. לעומת ווינדוס, בלינוקס, כל קובץ מערכת כמעט הוא קובץ טקסט (ascii) שניתן לקרוא ולערוך בחופשיות

חומרה

דרייברים

בלינוקס, דרייברים עובדים ברמת ה-Kernel. הכי בגדול, זה או שה-Kernel תומך בחומרה שלך, או שלא. אם אין תמיכה, זה כנראה בגלל אחת מכמה סיבות: 1. חומרה חדשה מדי: אף אחד עדיין לא כתב Kernel driver code 2. החומרה אקזוטית מדי: כל דיסטרו מקמפלת את ה-Kernel קצת שונה; יש אפשרות למצוא Kernel Driver Code קיים שלא קומפל במערכת שלך ולקמפל אותו בעצמך 3. המפתח של החומרה לא מנגיש את המידע הדרוש לכתיבת Kernel Driver Code

devices

• במציאות העכשווית, מכשירים שונים יצאו ויכנסו מפורטים שונים, ולכן קשה לעקוב אחרי השמות שלהם. אז איך?
• אפשר לראות את כל ה-devices בתיקיה /dev

• ה-Pattern הכללי הוא: ![[Pasted image 20250125203335.png|500]]

• המתודה למציאת שם של device:

• נעשה tail כדי לעקוב אחרי /var/log/messages או אחרי /var/log/syslog (יתכן שצריך סודו)
• במערכות מודרניות עם systemd אפשר גם פשוט sudo journalctl -f
• ננתק ונחבר את ה-device, ונראה עדכון בסגנון הבא: Jul 25 13:15:08 ratel kernel: sd 6:0:0:0: [sdc] Attached SCSI
• אפשר גם באמצעות [[מילון BASH#lsblk#|lsblk]]
• ברגע שיש לנו את השם, הדרך לרפרר ל-device היא /dev/name - זה בגלל שהקבצים של ה-device יושבים ב-/dev בשם של ה-device
• אם יש לנו /dev/sdd1 למשל (או כל מקרה שבו יש מספר אחרי ה-device name) - מדובר כנראה במספור של partitions

פורמטים וקבצים

Text files

Some of these representation systems are very complex (such as compressed video files), while others are rather simple. One of the earliest and simplest is called ASCII text. ASCII (pronounced "As-Key") is short for American Standard Code for Information Interchange. This is a simple encoding scheme that was first used on Teletype machines to map keyboard characters to numbers. Text is a simple one-to-one mapping of characters to numbers. It is very compact. Fifty characters of text translates to fifty bytes of data. It is important to understand that text only contains a simple mapping of characters to numbers. It is not the same as a word processor document such as one created by Microsoft Word or LibreOffice Writer. Those files, in contrast to simple ASCII text, contain many non-text elements that are used to describe its structure and formatting. Plain ASCII text files contain only the characters themselves and a few rudimentary control codes such as tabs, carriage returns and line feeds. Throughout a Linux system, many files are stored in text format and there are many Linux tools that work with text files. Even Windows recognizes the importance of this format. The well-known NOTEPAD.EXE program is an editor for plain ASCII text files.

(טקסט במובן הפשוט זה ASCII, איפה שכל פריט הוא אות ויש לו רק מס' - כלומר המיקום שלו ב-string)

linefeed vs carriage return

• הטרמינל של ווינדוז, DOS והטרמינל של לינוקס - UNIX - לא מפרמטים סוף של שורה באותו אופן.
• מערכות UNIX משתמשות ב-Linefeed, באופן הבא line $ (דולר סיין בסוף השורה) - ערך ASCII 10
• באותו זמן, DOS משתמש בתו בשם carriage return שהערך שלו הוא ASCII 13
• יש כל מיני תוכנות בשם dos2unix ו-unix2dos שממירות קבצים בין שתי המערכות, אבל בגדול כל ההמרה היא להחליף את כל ה-carriage return ב-linefeed
• אפשר לראות איך קובץ מפורמט באמצעות, למשל, cat -A [[מילון BASH#cat#|כמו שמפורט כאן]]

Document Formatting Systems

• אחת הסיבות ש-UNIX פופולרית בקרב משתמשים טכניים ומדעיים היא התמיכה בפורמטים רבים של מסמכים
• היסטורית, הפורמט החשוב הראשון שנכתב ל-LINUX (והניע את הפיתוח של כל המערכת) הוא .roff
• כיום, שולטות שני סוגים של תוכנות: המשכים של roff כמו nroff ו-troff; ומערכת TEX (נהגה tek)
• תוכנות roff מכינות טקסט להצגה ב-typesetter style - כלומר כרצף של טקסט ורווחים, "שורת טקסט". רוב המדפסות תומכות בזה. יש במשפחה את eqn למשוואות ואת tbl לטבלאות

• משפחת TEX די הדיחה את roff, אבל יש ספרים שלמים על המערכת הזו ולא ניכנס לזה. גם היא מפרמטת טקסט כ-typesetter output. טק לא מותקנת מראש ברוב המערכות.

• חידוד: כיום, אנחנו רגילים להסתכל על מסמכים באמצעות תוכנה אחת, שהיא graphical word processorr - זה אומר שהיא גם יודעת לקרוא קובץ עם מידע טקסטואלי ולהמיר אותו ל-display text (typesetter) - החלק הזה נקרא composition; וגם יודעת לפרמט את הטקסט הזה באופן גרפי to apply the formatting - החלק הזה נקרא processor

• כלומר, אנחנו פותחים וורד, וכותבים את הטקסט תוך כדי שאנחנו מפרמטים אותו
• כש-roff פותחה, יצירת מסמך עדיין הייתה תהליך דו-שלבי: כתבנו את הטקסט כדאטה פשוטה באמצעות compositor (נניח vim), ופרמטנו את הטקסט באמצעות משהו כמו roff או TEX - הprocessor
• השימוש בprocessor הוא באמצעות תגי markup שמכניסים לטקסט עם הcompositor

PostScript

• כשהתבצע המעבר מהדפסה בסגנון typesetter (מחקה מכונת כתיבה - המדפסת מטביעה תווים קבועים לפי חוקיות מסוימת) להדפסה גרפית ("לייזר" ) - להעביר מידע על כל "נקודה" בדף (dot per inch - DPI) היה מאוד כבד מבחינת משקל של קובץ ההדפסה.
• לכן פותחו שפות PDF - page description languages; הן בעצם מכילות מידע טקסטואלי לגבי ההדפסה הגרפית שתתרחש
• הדומיננטית היא PostScript של Adobe...
• בהתחלה ה-postscript interpreter היה על המדפסת, עם התקדמות המחשבים המחשב התחיל לתפקד כ-RIP - Raster Image Processor
• ללינוקס כיום יש את CUPS - Common Unix Printing System שמספקת תוכנות ניהול הדפסה ודרייברים, ואת Ghostscript שמתפקדת כמפרש PostScript ואחראית על ה-RIP

libs & binaries (& compilation)

(הסבר מעולה מרדיט אבל טיפטיפה ארוך)

I suck at ELI5...so not really trying at it...hope it's still not too hard to follow.
If you write a program/application you don't want to do everything from scratch. If I write a paint program for example I am not very interested in writing code that draws a menu bar on the screen. Also I am not very interested in how to spell-check words of the text I can put in the images. Many other people already worked on that and did a great job. It would be great if I could just reuse their work and concentrate myself on the task I am interested in...making a paint program.
And this is what libraries (libs) allow me. They are program code that isn't meant to run alone. It is meant to be included by applications. So I have my paint binary (probably in /usr/bin) which then makes use of libQtWidget.so (libraries are usually in /usr/lib) for example to draw the menu bar.
In fact the majority of code ran on your system is code that is shipped as library. All graphical toolkits (gtk, Qt...) are libraries, accessing files is done through libraries (glibc), openGL is a library, unicode support...really, almost everything. Programs are basically calling library functions and giving them special meaning by how they combine them and how they process the data they get this way.
One other advantage of libraries is that the are reusable by many programs. This can have pretty big resource savings. By having the code to draw application menus in one library it only needs to be loaded once in your memory not the same code again and again for every program that does this.
So far we only talked about compiled binaries. It's a bit confusing because actually libraries and programs are both binaries...but usually "binaries" it more used only for the programs and libraries are called libraries. But technically there is not much difference (simplified...there is a difference in their structure)...they are machine code created from sourcecode.
So to sourcecode now. Afraid you address a bit more there with your question as you realize..so lets go through it all.
First there are the sourcecode files. Those are text files written in a specific programming language (C, C++, java...). To turn these files into binaries they must be compiled with a compiler (usually gcc). The work of compilers is incredibly complex nowadays but for a basic understanding I think it's fine to say that a compiler looks the text and transforms it into number values that the processor understands. This is machine code. Machine code is basically numbers that specific very simple commands (like "load the content of the memory cell xyz"). Compilers break down the programming language in those simple commands and encode them in a way the processor understands.
But most programs are not just one sourcecode file that needs to be turned into machine code by the compiler. For simplicity programs are usually split into several source code files where all must be complied and then in the end combined. To help with this process we have "make". Make is basically a tool that allows writing rules like "Take all files ending in .cpp and use them as input for the program gcc (compiler). So make is a organization tool that helps compiling a lot of file with one command. (Actually...make can be used for other purposes as well...it is not really bound to compiling but that is the predominant use case).
I left out one part so far....the combining of the compiled files in one program at the end. This is also done by make...but is a different step than compiling. This is called "linking"...and it does two things. First it combines all the compiled program files in one executable. But second it also looks up all library functions the program calls and then prepares the executable to load those libraries when needed. Can imagine it a bit like creating one big list with all library functions a program needs, where the library with that function can be found it...and where exactly in the library the function can be found. After this step we have a executable that can be run or a library that can be included by other programs.
All fine so far....this all works pretty well and would be enough to compile programs. But....we don't only want our program to compile exactly on the system it was written..we want it easily possible to compile our program on other systems and even on other processor architectures as well. Because of this we add one more step "above" the make step.
This is what you mention with autotools (./configure) or cmake as an alternative example. The task of these is to collect information about the system they run on then create Makefiles for make (the files that define the rules) that work on this system. For that they collect for example which libraries are available on a system, where those libraries can be found in the filesystem, what compiler is available (gcc, llvm, icc..), what processor do we have... With all those infos they then write appropriate makefiles which you then use to compile the program with "make".

Packaging System

ה-packaging systems הבולטות הן .deb של דביאן ו-.rpm של redhat ![[Pasted image 20250125193220.png]]

ה-package file הוא קובץ ה-deb או ה-rpm, הוא כולל את כל הקבצים שמרכיבים את החבילה, בנוסף ל-metadata (שם, גרסה וכו') ו-pre & post installation scripts שמטפלים בהגדרות שונות. ה-package file נוצר ע"י package maintainer, הוא לוקח את ה-source code מהאפסטרים (מהמפתח), יוצר את כל הסקריפטים באופן שמותאם לדיסטרו שהוא מכוון אליה, ומשחרר package file. ה-packages יושבות ב-repository, לרוב הדיסטרוז יש כמה רפוזיטורים לשלבים שונים בפיתוח של החבילות - חבילות יציבות, חבילות לקראת שחרור, חבילות בניסיון, וכמובן third party repositories שחבילות יושבות עליהם בנפרד, אם בגלל זכויות יוצרים או סיבות אחרות.

ה-package tools שנשתמש בהם מתחלקים ל-High-level ו-Low-Level. הלואו-לבל הם הכלים שמתקינים ומסירים חבילות ההיי לבל מטפלים בקריאת מטא-דאטה אודות החבילות ופענוח dependencies הלואו-לבל טול שלנו הוא לרוב ה-packaging system עצמו - rpm בפדורה וכו', אבל בדביאן זה דווקא נקרא dpkg ההיי-לבל טול שלנו זה לרוב מנהל החבילות: dnf או yumבפדורה, apt בדביאן

![[Pasted image 20250125194147.png]]

dpkg -l או rpm -qa כדי לקבל רשימה של כל החבילות (מהלואו-לבל טול)

לפני שהיה flatpak, snap וכו:' היה בניינטיז "static linking" - שילוב של החבילה וכל ה-dependencies שלה לבינארי אחד גדול.

מושגים

UEFI

התוכנה הראשונה שעולה במחשב, שמריצה את מערכת ההפעלה. היא יושבת על החומרה ולרוב היא פרטית/קוד סגור, מה שקצת מקשה להגיד שיש לנו Open source softwares. יש ניסיון לכתוב UEFI פתוח - coreboot ו-linuxBIOS, אבל רובינו עדיין עם מה שהיצרנית של המעבד נעלה עליו. המטרה של LIBREBOOT, COREBOOT וכו' היא להחליף את ה-UEFI, שתמיד מגיע עם ברירת מחדל נעולה, שהיצרנית של המעבד (אחת מכמה חברות ענק) יצרה. זאת משימה מורכבת וההצלחה של הפרויקטים האלה היא רק חלקית - חלקים מהקוד הסגור של ה-UEFI הם "Hard coded" במובן שהם מודפסים על לוח האם - וכדי לרוץ, האלטרנטיבות הפתוחות משתמשות בחלקים האלה.

POSIX & BSD

שני סוגים שונים של מערכות UNIX לינוקס היא POSIX מקינטוש היא BSD (כמו גם FREEBSD כמובן)

POSIX: בשנות ה-80, UNIX הפכה למערכת מאוד פופולרית, והרבה מאוד חברות שונות קנו זכויות עבורה מ-AT&T המפתחת והתחילו להגביל את התאימות של תוכנות UNIX (פורמטים שמיועדים רק לגרסה של כל חברה וכו'). זה נקרא 'עידן הבלקניזציה' של UNIX. באמצע שנות ה-80 נוסד גוף בשם IEEE - Institute of Electrical and Electronic Engineers הגוף הזה התחיל לפתח סטנדרט שיכלול את כל ה-APIים, תוכנות shell ו-shell utilities שצריכות להימצא במערכת הפעלה מסוג UNIX-LIKE. השם שנבחר לסטנדרט הזה הוא POSIX - Portable Operating System Interface

shell שעוקב אחרי הסטנדרט הוא POSIX Shell/Narrow Shell

הסיבה שאומרים portable היא שקבצים של POSIX אמורים לרוץ על כל POSIX MACHINE אחרת... לכאורה. יש טהרני יוניקס שלא אוהבים את לינוקס כי היא די בגדה באידאל הזה של פורטביליות... עוד לפני כל הבלגן של מנהלי החבילות וה-dependency hell שאנחנו נמצאים בו: היא שמה את באש להיות ברירת המחדל במקום ה-sh shell הצרה ביותר (סטנדרט POSIX).

GNU

קיצור של GNU'S NOT LINUX. בעצם, GNU הוא פרוייקט שהמטרה שלו היא לייצר אלטרנטיבה חינמית ל-UNIX. כמו שאנחנו יודעים, חוץ מה-KERNEL של ה-OS, היא תלויה בהמון "תוכנות טרמינל" כמו קומפיילרים, כותבי קוד, פונקציות ועוד. ה-suite הזו נקראת userland והיא מה ש-GNU מספק ללינוקס. פרוייקט GNU קשור ל-FSF (Free Software Foundation) ומושתת על עקרונות של תוכנות חינמיות. כל התכנים שלו תחת רישיון GNU General Public License (GPL). תוכנות מפורסמות ש-GNU כולל: - bash - gcc (gnu compiler collection) - make - a build automation tool - grep, awk, sed - ls, cat, cp ועוד - glibc (gnu C library)

כשמבינים כמה תוכנות טרמינל בסיסיות GNU תורם ל-LINUX, אנחנו מבינים למה מערכת ההפעלה בפועל היא שילוב של LINUX (הקרנל) ושל GNU (הסוויטה) - GNU/LINUX.

היסטורית: GNU בא לפני לינוקס, הוא נוצר ב-1983 ולא היה לו קרנל. לינוקס נוצר ב-1991 והוא היה רק קרנל. ב-1992 השניים התחברו...

shell program

תוכנת ה-shell שאנחנו מריצים בלינוקס היא bash, כלומר born again shell. מערכות UNIX אחרות משתמשות ב-SHELLים אחרים. - sh (bourne shell) הגרסה הישנה של באש - ksh (korn shell) - solaris, AIX - csh & tcsh - c shell & enhanced c shell, פופולאריים במערכות BSD - zsh - יש מי שמריצים את זה על לינוקס. הדפולט של מקינטוש מאז 2019 בערך - dash - minimal POSIX shell - fish - עוד של פופולארי שיש המריצים בלינוקס במקום באש. לא בא עם אף מערכת פופולארית.

רוב ה-shells יהיו POSIC COMPLIENT מבחינת הסטנדרטים של shell program

System Calls

ל-CPU שלנו יש שני מצבי פעולה מקבילים: USER MODE ו-KERNEL MODE מצב KERNEL הוא מצב מיוחד שבו למעבד יש הרשאות לחומרה - למשל לשכתב חלקים בדיסק מצב USER הוא מצב שבו המעבד יכול לבצע פעולות ולתת OUTPUT בלבד, בלי לגעת בחומרה מערכת ההפעלה רצה על KERNEL MODE וכל התוכנות של היוזר רצות על USER MODE

ההפרדה הזו נועדה למנוע מתוכנות אקראיות לגשת לחומרה בלי השגחה.

אז איך תוכנה ניגשת בכל זאת לחומרה, נגיד קוראת קבצים מהדיסק? היא מבקשת ממערכת ההפעלה לבצע פעולות שונות ב-KERNEL MODE בשמה, באמצעות ממשק שנקרא SYSTEM CALLS ובנוי כספריית C ![[Pasted image 20250126033334.png]]

• אחת הסיבות העיקריות שתוכנות הן os specific ולא רק cpu architecture specific היא שממשקי ה-system calls של כל os עובדים אחרת. fork לא עובד כמו createprocess וכן הלאה.
• חוץ מה-SYYSTEM CALLS שבתמונה, יש עוד מלאנתלפים סיסטם קולז. אפשר למצוא אותם בקבצי המערכת.
• צריך לשים לב שה-SYSTEM CALLS ממוספרים! זה חשוב כי כשהסיסטם קול מופעלת, המחשב מפרש אותה כמס' שלה. עוד סיבה שיש הבדלים בין מערכות הפעלה היא שהמספור שונה בכל אחת.
• בנוסף, לכל SYSTEM CALL יש פרמטרים אפשריים. האופן שהפרמטרים האלה בנויים ויושבים על הזיכרון שונה בכל OS.

PuTTY

• תוכנה ל-Windows שנועדה לאפשר להתחבר ל-remote host ב-[[מילון BASH#ssh#|ssh]]
• בגדול הייעוד שלה הוא לאפשר לווינדוז להתחבר ל-remote linux machines וכו'

קומפילציה

• התהליך של להפוך קודמקור (בכל שפת תכנות) לשפה של המעבד (שפת מכונה)
• כשיש לנו חבילה ב-repo או בקונטיינר, היא כבר מקומפלת, אבל לפעמים צריך לקמפל לבד כדי להשיג גרסה חדישה יותר או כדי להשיג את החבילה בכלל.
• שפת מכונה היא הקוד הבינארי עצמו, שכולל הוראות מאוד מאוד פשוטות כמו "תוסיף את הבייט הזה" או "תצביע למיקום הזה בזיכרון" - נכתבות במה שנקרא numeric code
• כיום, בין שפת התכנות לשפת המכונה, יש לנו שפת אסמבלי Assembly Language, שפועלת על mnemonics - הוראות קצת יותר מורכבות למעבד כמו CPY (קופי) ו-MOV (להזיז)
• קוד באסמבלי עובר למעבד באמצעות Assembler
• עדיין כותבים באסמבלי דברים כמו דרייברים
• שפות תכנות מכונות high-level programming languages, הראשונות יצאו בשנות החמישים - FORTRAN ו-COBOL
• השפות הדומיננטיות הן C ו-C++
• שפות תכנות גבוהות מתורגמות לשפת מכונה באמצעות קומפיילר Compiler - ולפעמים הן מועברות קודם כל לאסמבלי ואז מתורגמות שוב באמצעות אסמבלר

• כשאנחנו מקמפלים, יש עוד תהליך שקורה במקביל: linking (קישור) בעצם, זה לא הגיוני שלכל תוכנה שצריכה להריץ קובץ יהיה פרוטוקול משלה לביצוע של זה. יש קוד אחד שאחראי על קריאת קבצים, והוא משותף לכל התוכנות שצריכות להשתמש בפרוטוקול הזה.

  לפרוטוקולים האוניברסליים האלה קוראים routines (רוטינות) והכל נכללות ב-ספריות (כתוב על זה איפשהו במחברות), Libraries, שהן כשמן, ספריות משותפות של רוטינות. הספריות נשמרות ב-/lib או ב-usr/lib

• בתהליך הקומפילציה, יש תוכנה שנקראת ה-Linker שאחראית על יצירת הקישור בין הקומפיילר לספריות השונות שהקוד שלנו מנצל

• התוצאה של תהליך הקימפול היא קובץ exe שניתן להריץ

האם כל תוכנה דורשת קימפול? - לא, הכרנו כבר תוכנות shell - סקריפטים - שלא דורשות קימפול. מדובר בכל התוכנות שנכתבות בשפת scripting, ידועות כ-Interpreted languages השפות האלה די פופולריות כיום וכוללות את Perl, Python, PHP, Ruby ועוד

בשפות מהסוג הזה, התוכנה נכנסת ל-Interpreter (למשל ה-shell) כאינפוט, והוא קורא ומבצע את ההוראות שבהן.
התוכנות האלה בד"כ איטיות יותר מתוכנות מקומפלות, כי התרגום לשפת מכונה צריך להתבצע בכל הרצה מחדש. **תוכנה מקומפלת תורגמה כבר מראש ל-executable file, כלומר לקוד בינארי**
למה הן פופולריות בכל זאת? **כי לא צריך לקמפל.** כלומר: אנחנו משתמשים באינטרפרטר כדי להריץ לפי ההוראות, ולא צריכים קבצים בינאריים שיוכלו להמשיך לרוץ באופן עצמאי. יותר קל לערוך את הקוד ולשגר אותו שוב בלי לקמפל תוכנה ענקית מחדש.

• הקומפיילר המקובל עבור שפת C בלינוקס הוא gcc, בד"כ לא מותקן מראש, לפעמים יש לדיסטרו שלנו מטא-חבילה של פיתוח תוכנה, שיכללו בה קומפיילרים. משתמשים בה יחד עם הפקודה make

תהליך הקומפילציה

• נוריד את ה-Source code לתיקיה בשם src
• קוד שאנחנו סתם משחקים איתו נשים ב-~/src; קוד שמותקן עם המערכת ישב ב-/usr/src; קוד שנועד לשימוש ע"י מספר יוזרים ישב ב-/usr/local/src (זו תבנית שנכונה לעוד דברים, נגיד ל-bin, כלומר binaries...) קבצי ה-readme:

• תוכנות שמשתייכות ל-GNU עוקבות אחרי סטנדרט לקבצי תיעוד: README, INSTALL, NEWS, COPYING הקבצים האלה מכילים מידע על התוכנה, תנאי שימוש ורשיונות, והוראות בניה לרוב חשוב לקרוא את README ואת INSTALL

• נחפש קבצים עם פורמט .c אלה הם קבצים של קוד בשפת C. התוכנה לרוב תתחלק למס' מודולות, modules, כלומר לכמה קבצים. מדובר בקבצי טקסט שאפשר לקרוא ככאלה קובץ .c הופך לקובץ 'אובייקט' (.o) במהלך הקימפול, לפני שנוצר קובץ בינארי

• נחפש קבצים עם פורמט .h אלה קבצי Header, גם הם קבצי טקסט, הם כוללים דקלרציות (הכרזות) על רוטינות שנכללות בכל אחד מקבצי התוכנה, או בספריות המשותפות של המערכת. (הספריות גם הן כוללות קבצי .h, שמסבירים לתוכנות שקוראות אותם בדיוק איפה במערכת נמצאת כל רוטינה ומה הפונקציות שלה) קבצי ה-.h של המערכת נמצאים ב-/usr/include הכוונה היא שהם כוללים פירוט של כל הרכיבים שדרושים להרכבת התוכנה השלמה; הם מפרטים גם איזה מידע מתוך ה-source code מרכיב אותה, וגם איזה מידע מחוץ ל-source code, כלומר אילו ספריות מרכיבות אותה.

  קבצי .c (קוד) מרפררים לקבצי .h (הדרז) באמצעות שורות כאלה: #include "file.h" (בתוך קובץ סי המשמעות היא שכאשר הקומפיילר קורא את קובץ הסי, נאמר לו לקרוא את קובץ ההדר כדי לדעת אילו רוטינות (שכתובות במקומות אחרים בקוד או בספריות המערכת) משתתפות בקוד של קובץ הסי.

פקודות: - בגדול, כדי לקמפל צריך שתי פקודות: ./configure (כשאנחנו בתוך התיקיה של הסורס קוד) make אחרי הראשונה כדי לבנות

• ה-configure היא shell script, קובץ שקיבלנו כחלק מהסורס קוד רוב התוכנות כתובות כ-portable; כלומר, הן יודעות להיבנות על מגוון מערכות UNIX, כשלכל אחת יש פרוטוקול מעט שונה. קובץ הקונפיגור הוא סקריפט שמתאים את הוראות הבניה למערכת הנתונה, וגם מוודא שכל ה-dependencies לבניה קיימות במערכת אם לא קיבלנו שגיאות באאוטפוט - הקונפיגורציה צלחה

• התוצאה של קונפיגורציה היא יצירה של כמה קבצים חדשים בתיקיית הקוד שלנו. החשוב ביניהם הוא makefile ה-makefile נכתב ע"י configure כדי לספק את הוראות מותאמות לפקודת make, שתבנה לבסוף את התוכנה.

  מדובר בקובץ טקסט שאפשר לקרוא ולערוך ככזה.

  קובץ ה-makefile נכתב לאחר ש-configure קראה את הקבצים ושרטטה את הקשרים ביניהם באופן שמותאם למערכת; התוכן שלו מתאר בצורה הסופית את כל הקשרים וה-dependencies שמרכיבים את התוכנה השלמה; הוא יכלול הגדרה של משתנים רבים בחלקו הראשון, ושימוש בהם בחלק השני. בגדול, כל השורות בחלקו השני הן הצבעה על קבצי קוד, פירוט ה-dependencies שלהם, ופקודות להרצה של הקוד לאחר שיש את כל המשאבים. בהרבה מקרים לא נראה פקודות, כי הן הוגדרו בשורה קודמת ע"י הוראה כללית, שמכוונת לכל קובץ .c - .c.o: $(CC) -c $(CPPFLAGS) $(CFLAGS) $< הפקודה הזו אומרת להפוך את קובץ הסי לקובץ אובייקט, כלומר לקובץ .o

• אחרי שיצרנו makefile, נריץ את הפקודה make בתיקיה בה הוא נמצא התוצאה, אם הצלחנו, תהיה גם קבצי ה-.o שישארו בתיקיה, וגם קבצי ה-exe שביקשנו ליצור

  ה-Make היא פקודה חכמה שלא תבנה מחדש תיקיה שכבר בנינו; אם היא מוצאת את קבצי ה-.o שדרושים לבניה, היא לא תבנה שוב! באותו אופן, אם מחקנו קובץ .o כלשהו שדרוש לתוכנה, או במצב שבו קובץ היעד (.o) ישן יותר מאחד מקבצי המקור (.c) שמרכיבים אותו - הכוונה היא לתאריך השינוי האחרון; ה-Make יודע לזהות שהתבצע עדכון/שינוי בקוד המקור - ולעדכן את התוכנה הבנויה בהתאם. זה משרת מפתחים מאוד, כך ניתן לבנות תמיד לפי הקוד העדכני.

• בקוד שבנוי היטב, יש לנו קובץ INSTALL - הוא נועד להרצה אחרי שבנינו את התוכנה עם make, והוא כולל הוראות בניה נוספות, שמבצעות את ההתקנה הסופית של הקבצים על המערכת (כדי שתהיה לנו תוכנה מותקנת ולא סתם קובץ exe) זו המשמעות של הפקודה הידועה make install, שמגיעה תמיד אחרי שהרצנו configure ואחריה make אנחנו מתקינים קבצים בתיקיות המערכת, לכן צריך תמיד לעשות sudo make install

  למה זה לא פשוט עניין של להעתיק אותם למקומות הנכונים? למה זו בניה?

File system & paths

Standard disk partitions

A standard disk partition scheme for Linux typically includes the following partitions:

1. EFI System Partition (ESP) (If using UEFI)
   Mount point: /boot/efi
   File system: FAT32
   Size: 100–500 MB
   Used to store bootloaders for systems booting in UEFI mode.
2. Boot Partition (Optional)
   Mount point: /boot
   File system: ext4 (or other Linux-supported file system)
   Size: 500 MB – 1 GB
   Contains the Linux kernel and related boot files. Some setups include it if the bootloader requires it.
3. Root Partition
   Mount point: /
   File system: ext4, btrfs, or others
   Size: 20 GB+ (depending on your needs)
   Contains the operating system, applications, and system files.
4. Home Partition (Optional but recommended for desktops)
   Mount point: /home
   File system: ext4, xfs, or others
   Size: Depends on available disk space
   Stores user data and personal files.
5. Swap Partition
   Mount point: None (used by the kernel)
   Size:
   Equal to RAM for hibernation.
   Otherwise, 1–2× RAM (depending on usage).
   Used for virtual memory when RAM is full.
6. Data or Other Partitions (Optional)
   Mount point: Custom (e.g., /data or /var)
   Size and file system: As needed for specific purposes like databases, media storage, etc.

Example Partition Table

For a 500gb disk:

Partition	Mount Point	Size	File System
ESP	/boot/efi	500 MB	FAT32
Boot	/boot	1 GB	ext4
Root	/	50 GB	ext4 or BTRFS
Home	/home	400 GB	ext4
Swap	(none)	8 GB	Swap Area

You can adjust the scheme based on your disk size and needs. For advanced setups (e.g., LVM, RAID, btrfs snapshots), the partitioning scheme may differ.

אפשרויות נוספות:

1. /var (Variable Data Files)
   Purpose:

Stores variable or dynamic data that changes during system operation.
Examples:
Logs: /var/log/ (e.g., syslog, auth.log)
Caches: /var/cache/
Spools: /var/spool/ (e.g., print queues, mail queues)
Temporary files: /var/tmp/
Databases: /var/lib/ (e.g., MySQL, PostgreSQL data files)
It ensures that dynamically generated or updated content doesn’t clutter the root partition.
Why It's Not Essential:

On most systems, /var can reside on the same partition as /.
For systems without high levels of logging or databases, a dedicated /var partition is unnecessary.
However, on servers or environments where logs, caching, or database data are extensive, a separate /var partition is advisable to prevent these files from filling up the root partition.

1. /usr/local
   Purpose:

Stores software installed manually by the system administrator, separate from the distribution's package manager.
Examples:
Locally compiled software (e.g., programs built from source).
Custom scripts and tools.
This separation prevents conflicts with the package manager and keeps custom files isolated.
Why It's Not Essential:

Many systems don't require manually installed or compiled software and can rely solely on package managers.
If custom software is needed, /usr/local is often located on the root partition by default, so no separate partition is mandatory.
Why They're Often Not Separate by Default:
Disk Space Management:
Unless you expect /var or /usr/local to grow significantly, dedicating partitions for them could result in wasted space.

Simplicity:
Modern Linux systems often favor a simpler partitioning scheme (e.g., just /, /home, and swap), particularly for desktop users.

Specific Use Cases:
Separate /var is more common on servers with heavy logging or databases, while /usr/local separation is mostly for administrators needing to isolate custom software.

Filesystem Tree

• בכל מערכת UNIX, כל ה-storage devices השונות שלנו הן חלק מ-Filesystem Tree אחד, שהחומרה השונה "מתחברת" לנקודות שונות בו.
• זה בשונה מ-Windows למשל, שיש לו עצים שונים עבור D, C וכו' (כל כונן)
• כדי לצרף חומרה ל-Tree אנחנו עושים לה mount
• יש קובץ בשם /etc/fstab, שהמשמעות של שמו היא "File System Table".
  • הקובץ הזה מפרט את כל המכשירים (רובם וירטואליים, דיסק פרשטישנז) שיש לעשות להם mount מיד עם ה-boot ![[Pasted image 20250125200629.png]]

הסבר על המידע שרואים ב-fstab: עמודה 1: שם ה-Device. בעבר היה נהוג שזה שמות בפורמט /dev/sda1, היום יותר נהוג לתת שם כ-LABEL=NAME, פשוט כי יש הרבה מכשירים שנכנסים ויוצאים מהמחשב ב-USB

עמודה 2: Mount point. זו "הנקודה" שבה המכשיר מתחבר ל-file system tree. הכוונה היא פשוט ל-path שממנו מתחיל ה-listing של המכשיר. לצורך העניין, root יושב ב-/. זה אומר שהחל מ-/, אנחנו בעץ של ה-storage שעשינו לו mount כ-root.

עמודה 3: סוג מערכת הקבצים. אם EXT4 שייחודי ללינוקס, או משהו כמו btrfs, FAT32

עמודה 4: אפשרויות מיוחדות. למשל read only. לעתים נראה את זה בפורמט של r ו-rwעבור קריאה/קריאה כתיבה עמודה 5: "תדירות" - קובע תדירות לגיבוי של המערכת באמצעות פקודת dump עמודה 6: "סדר" - קובע את סדר הבדיקה של המערכת באמצעות פקודת fsck

Linux Filesystem Hierarchy Standard

המערכת קבצים של לינוקס דומה לשל מערכות unix אחרות. יש סטנדרט בשם של הכותרת, לא כל דיסטרו נצמדת אליו אבל בד"כ כן.

(צריך לשבת על זה יותר ברצינות בהמשך)

dotfiles (.config)

הגדרות אישיות של המשתמש יושבות ב-
~/.config

/etc/

הגדרות רוחב של המערכת בנוסף יושבים פה סקריפטים שמתחילים system services ב-boot /etc/crontab מגדיר איזה automated tasks יש שמופעלות עם קרון /etc/fstab טבלה של דיסקים והמאונט פוינטס שלהם /etc/passwd רשימה של יוזרים במערכת

/var/

App data and cache: קבצים שמיועדים להשתנות - דאטהבייסים, קאצ', ספול פיילז וכו' - Located under ~/.var/app/<app-id>/. - Subfolders: - cache/: Temporary files, logs, and caches. - config/: Configuration files specific to the app. - data/: Persistent app data, such as user profiles, databases, or downloaded files. - /log לוגים חשובים של המערכת. בעיקר /log/messages ו-/log/syslog

/bin/ ו- /usr/bin -ו ~/bin

רוב הלינוקסים בימינו זנחו את /bin לטובת /usr/bin

What Does /usr/bin Typically Contain?

1. User-Level Executables:
   • Programs and utilities that are not essential for booting or single-user mode but are intended for general use by all users.
   • Examples:
     • bash, ls, grep, awk
     • Applications like vim, nano, python
2. Application-Specific Binaries:
   • Executables for programs installed via the system's package manager (e.g., firefox, thunar).
3. Scripts and Helper Tools:
   • Small helper programs or scripts that are part of larger packages.
     Difference Between /bin and /usr/bin
4. /bin:
   • Contains essential programs needed to boot and repair the system.
   • Minimal set of binaries (e.g., sh, cp, mv, rm).
5. /usr/bin:
   • Contains a much larger set of executables, including user-installed applications.
   • Often includes tools not critical for boot or rescue operations.

לעומת שני אלה, יש את
~/bin
שזו פשוט תיקיה ריקה לשים בה binaries אקראיים של היוזר (היא ב-Path אצלי וממנה אני מריץ אקסקיוטבלז)

/lib ו- /usr/lib

Contains shared library files used by the core system programs. These are similar to dynamic link libraries (DLLs) in Windows. This directory has been deprecated in modern distributions in favor of /usr/lib. (מסתבר שבווינדוז ספריות זה קבצי dll, יש הסבר טוב על ספריות [[לינוקס - כללי#libs & binaries (& compilation)#|כאן]])

/lost+found

לכל דיסק או פרטישן עם מערכת קבצים של לינוקס (btrfs ext4 וכו') תהיה תיקיה כזו. היא משמשת לשחזור קבצים במקרה של file system corruption אלא אם קרה משהו רע התיקיה הזו תישאר ריקה

/media

On modern Linux systems the /media directory will contain the mount points for removable media such as USB drives, CD-ROMs, etc. that are mounted automatically at insertion.

/mnt

On older Linux systems, the /mnt directory contains mount points for devices that have been mounted manually.

/opt

The /opt directory is used to install “optional” software. This is mainly used to hold commercial software products that might be installed on the system.

/proc

The /proc directory is special. It's not a real file system in the sense of files stored on the hard drive. Rather, it is a virtual file system maintained by the Linux kernel. The “files” it contains are peepholes into the kernel itself. The files are readable and will give us a picture of how the kernel sees the computer. Browsing this directory can reveal many details about the computer’s hardware.

/root

This is the home directory for the root account.

/run

This is a modern replacement for the traditional /tmp directory (see below). Unlike /tmp, the /run directory is mounted using the tempfs file system type which stores its contents in memory rather than on a physical disk.

/sbin & /usr/sbin

system binaries כלומר בינאריז חיוניים לתפקו של המערכת, גישה שמורה לסופריוזר בלבד ברוב המערכות /sbin הושבת לטובת /usr/sbin /sys כוללת מידע על חומרה שהקרנל זיהה. דומה ל-/dev אבל יותר מפורט, כולל כתובות ממשיות של החומרה (?)

/tmp קבצים זמניים של כל מיני תהליכים במחשב. יש דיסטרוז שמרוקנים את זה בכל בוט

/usr התיקיה הכי גדולה ברוב המקרים. כוללת את כל התוכנות והקבצים שיוזרים רגילים משתמשים בהם /usr/local תוכנות שלא באו עם הדיסטרו אבל מיועדות לשימוש רוחבי (של כל המערכת ולא רק יוזר אחד) תוכנות שקימפלנו מהקוד-מקור שלהן לרוב ילכו ל /usr/lobal/bin לרוב זה ריק עד שהסיסטם אדמין שם פה משהו /usr/share כולל את ה-shared data של תוכנות שיושבות ב-/usr/bin (למשל קונפיגורציות, אייקונים וכו') /usr/share/doc דוקומנצטיות של שיט שמותקן במערכת

~/.local מכיל גם קצת קונפיגרציות שלא יושבות ב.config

הרשאות ויוזרים

בגדול מה שמייחד את unix זה שאנחנו לא רק במערכת שעושה מולטי-טסקינג, אלא גם במערכת של multi user. בעבר מחשבים היו גדולים מאוד, אז היה מחשב אחד מרכזי והרבה טרמינלים עם גישה אליו. כל הרעיון במערכת היוזרים וההרשאות זה לחלק את ההרשאות על חלקים שונים במערכת כדי שלא יפריעו זה לזה.

במודל של יוניקס, לכל קובץ/תיקיה (שהיא קובץ) יש בעלים, שהוא אחד ה-userים. היוזרים יכולים להיות ב-'קבוצות' יחד עם עוד יוזרים, שלכל המשתמשים שחברים בהן יש סט מסוים של הרשאות. אם היוזר נותן הרשאות לכל השאר, זה נקרא others או world

המידע על יוזרים יושב ב-/etc/passwd והמידע על קבוצות ב-/etc/group

חוץ מהיוזרים הרגילים, יש את הסופריוזר (תמיד uid 0) ועוד משתמשי מערכת

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

ההרשאות מתחלקות ל-3: - read access - write access - execution access

file attributes

כשאנחנו עושים ls -l לתיקיה, הערך הראשון שאנחנו רואים על קובץ הוא שיט שנראה כמו למשל -rw-rw-r-- זה נקרא file attributes האות הראשונה ברצף הזה היא הfile type ![[Pasted image 20250124181716.png|500]]

כל ה-9 ספרות שאחרי הראשונה נקראות file mode והן מייצגות מידע על הרשאות קריאה, כתיבה והרצה עבור הבעלים של הקובץ, יוזרים בקבוצה שהבעלים משויך אליה, וכל השאר.

![[Pasted image 20250124182010.png|500]]

![[Pasted image 20250124182303.png|500]]

/etc/sudoers

קובץ שמגדיר בתוכו איזה פקודות ניתנות לביצוע ע"י אילו יוזרים

• למה sudo או למה su?

  הבעיה עם "להריץ כמנהל" במונחים של ווינדוס היא שהיוזר תמיד פועל עם ההשראה הזו, ולכן גם וירוסים יכולים להשתמש בה. באופן מסורתי, בלינוקס היה root user/superuser שהוא עם הרשאות בלתי מוגבלות. יוזרים היו עושים su כדי להזדהות כיוזר הזה, ופועלים למעשה כמו admin בווינדוז. עם הזמן אפילו הייתה נטיה לתפעל את המחשב כ-root בכל זמן נתון כדי להימנע מסיבוכים. זה לא מוגן כ"כ. מאובונטו ואילך, הנוהג החדש היה לא להגדיר ססמה לסופריוזר/root בכלל, ולא להפעיל את היוזר הזה. במקום, כל ההרשאות הרלוונטיות של הסופריוזר הוגדרו ב-/etc/sudoers, כאשר הכוונה היא שכל יוזר שצריך את ההרשאות האלה ישתמש ב-sudo, אך ורק בזמן שהוא באמת צריך אותן.

תהליכים

מערכות יוניקס וביניהן לינוקס הן multitasking, כלומר הן מייצרות את האשליה שהן עושות כמה דברים בו זמנית, ע"י ניהול של processes שונים, שיש להם תור קבוע לקבל "סיבוב על המעבד"

init & systemd

כשהמערכת מופעלת, הדבר הראשון שקורה הוא שהקרנל טוען כמה תהליכים שלו ולבסוף מריץ תוכנה בשם init כיום מקובל ש-init מפעילה תהליך נוסף בשם systemd, והוא זה שמפעיל את שאר התהליכים במערכת. בעבר, init הייתה מפעילה 'init scripts' מהתיקיה /etc כדי להפעיל את כל מה ש-systemd עושה בימינו התהליכים של init ושל systemd נקראים daemon programs - המשמעות היא "תוכנה שרצה ברקע ועושה דברים בלי שיהיה לה ממשק משלה"

כשתהליך מפעיל בעצמו תהליכים נוספים, נוצרת היררכיה שהמערכת עוקבת אחריה, של parent process ו-child process

מידע שרואים ב-ps

בנוסף לכל תהליך יש PID (פרוסס איידי) כש-init הוא תמיד PID 1, וכמובן יש להם בעלות, משאבים שהם מנצלים וכו'
- TTY = Teletype כלומר: איזה טרמינל שולט בתהליך - TIME = כמה זמן מעבד התהליך צורך - STAT = הסטייט של התהליך ![[Pasted image 20250124202411.png|500]]

• לפעמים יש עוד אותיות אחרי הראשונה, אלה כל מיני states ייחודיים שאפשר לקרוא עליהם ב-man ps

טרמינל (כללי)

environment, startup files

הסביבה היא, כידוע, אוסף של משתנים שתוכנות נעזרות בהם בנוסף לקבצי הקונפיגורציה הייעודיים שלהן על מנת "להכיר" חלקים שונים במערכת. האופן שבו הסביבה מופעלת הוא כך: כשאנחנו נכנסים למערכת, bash מופעל וקורא סדרה של קבצים בשם startup files, שמגדירים את הסביבה המשותפת לכל המשתתפים, ולאחריהם עוד קבצי startup שמגדירים את הסביבה של כל יוזר. התהליך תלוי בסוג הסשן: - לוגין של: אם התחברנו באמצעות הססמה, כולל כשמתחילים סשן של ה-GUI - נון-לוגין של: כשאנחנו מפעילים סתם terminal emulator במחשב למשל ![[Pasted image 20250125000134.png|500]]

הקובץ הכי חשוב הוא כמובן ~/.bashrc, כל נון-לוגין של קורא אותו ורוב התוכנות קוראות אותו גם כשאתה בלוגין של.

לא רק bashrc חשוב, למרות שכל קובץ כאן כמעט מכיל שורה שאומרת "אם קיים bashrc תקרא אותו". כלומר, הסביבה מוגדרת בעוד קבצים. למשל: /etc/profile מכיל את החלק שקובע את ה-PATH ככה שהוא תמיד יקרא קבצים מ~/bin מעניין לדעת שהוא בנוי ככה: PATH=$PATH:$HOME/bin אנחנו חוזרים על משתנה בהתחלה של ההגדרה שלו כשאנחנו רוצים להוסיף עוד טקסט בסוף שלו (to append to it).

עריכת ה-environment

• מקובל שאת ה-PATH ואת המשתנים הסביבתיים מגדירים ב-~/.bash_profile
• ואת כל השאר ב-~/.bashrc

Text Editors

בטרמינל יש כמה טקסט אדיטורז פופולאריים. הכי ידוע ושימושי למטלות פשוטות הוא nano הסטנדרט האמיתי של UNIX הוא vi, שהרבה כמובן מחליפים ב-vim - Vi Improved. חוץ מזה יש לנו את emacs עצום המימדים שברוב המערכות לא מותקן מראש.

POSIX Shell/Narrow Shell

• חשוב לדעת שיש הבדל בין POSIX Compliant Shell לבין BASH ל-BASH יש יחסית הרבה פיצ'רים שהם מעבר לנדרש בסטנדרט של פוסיקס, ויש היגידו שהוא bloated. ומנגד, קיים מה שנקרא Narrow Shell, שזו shell שיש לה רק את הפיצ'רים ההכרחיים, ועל כן היא יותר מהירה (BASH נחשבת מאוד איטית). יש אנשים שבוחרים להתקין Narrow Shell Program, כמו dash, כדי להריץ דרכה את כל הסקריפטים שהם מריצים בד"כ ברקע, ולקבל ביצועים גבוהים יותר. ולכן יש מי שבוחרים לכתוב Posix compliant scripts...

• משמעות של כל זה היא שחשוב לא להשתמש ב-#! shebang באופן אוטומטי.
  הפאת' /bin/sh הוא לא באמת קובץ, אלא Symlink לתוכנת shell שנמצאת במקום אחר. ברירת המחדל היא שזה מלונקק ל-bash. אבל כאמור, יש אנשים שמשנים את זה, ולכן חשוב לכתוב /bin/bash עבור סקריפט שמשתמש בסינטקס של bash באופן ספציפי. (ו-/bin/sh עבור narrow shell).

shell prompt

• כברירת מחדל, ה-prompt (הטקסט שלפני כל פקודה) שלנו נראה משהו כזה: [me@linuxbox ~]$ יש לנו את ה-username, ה-hostname ואת ה-working directory $ מסמל שאנחנו בסשן שהוא לא סופריוזר (מסומן ב-#)
• כיצד הפרומפט מוגדר? באמצעות משתנה סביבתי בשם PS1
• אם נעשה echo $PS1 נראה משהו כזה [\u@\h \W]\$ (הפורמט של הפרומפט)

• האותיות האלה נקראות backslash escaped special characters, הנה מקרא של האפשרויות: ![[Pasted image 20250125015347.png]]

• חשוב לשים לב לשניים האחרונים - יש אותיות שנכלול ב-prompt string שהן non-printing, כלומר לא ייכתבו בפועל כשום טקסט, למשל /a

• חשוב לסמל לטרמינל שאנחנו מכניסים non-printing characters כי הוא צריך לדעת מה האורך של ה-string שלו בפועל

בעבר, אנשים התחברו למחשב המרכזי באמצעות כל מיני טרמינלים והייתה בעיה קשה של סטנדרטיזציה. ב-unix יש לנו שתי מערכות שנועדו להתמודד עם הסבך הזה: termcap ו- terminfo

איגוד התקנים האמריקאי, ANSI, יצר כמה סטנדרטים שקיימים ב-UNIX גם היום. ככה למשל אנחנו יכולים לתת ANSI Escape Code כדי לקבוע את הצבע של חלקים שונים ב-Prompt

![[Pasted image 20250125021032.png]]

• כדי לכתוב את ה-Prompt באדום פשוט נשים את התג המתאים בהתחלה: PS1="\[\033[0;31m\]<\u@\h \W>\$ " אבל זה כמובן ימשיך את ה-scope של הצבע גם למה שנכתוב בטרמינל... אם אנחנו רוצים לחזור לצבע אחר כשאנחנו מתחילים לכתוב, צריך לשים פקודת צבע חדשה בסוף של ה-prompt: PS1="\[\033[0;31m\]<\u@\h \W>\$\[\033[0m\] "

לצבוע את הרקע:

![[Pasted image 20250125022403.png]]

הסבר על המבנה של ה-ANSI COLOR CODE: מתחילים מ-033, שהוא octal value כלשהו (לא ניכנס לזה) \033 אחרי זה אנחנו מציינים בסוגריים המרובעות את ה-character attribute, אחריו semicolon ואחריו את הקוד של הצבע שאנחנו רוצים \033[0;30m] אומר "אנחנו נותנים פה קולוד קוד" (אוקטל 033), האות תהיה regular (0), והצבע שלה הוא שחור (30m) character attributes: 1 - בולד 4 - אנדרסקור 5 - בלינק 7 - היפוך הטקסט * הרבה טרמינלים לא נותנים לך להגדיר blinking

למקם את ה-cursor - חשוב לדעת שה-prompt לא מריץ את עצמו, אלא נכתב מראש לפי ההוראות ש-bash קיבל (זו לא פקודה שמריצים) - אנחנו יכולים לשים את ה-Prompt או חלקים ממנו במיקום שונה מהדפאולט - כדי לעשות את זה, צריך שבקוד של ה-prompt יהיו escape sequences שמזיזים את ה-cursor (הכתיבה ממשיכה בכל נקודה מאיפה שה-cursor עומד)

![[Pasted image 20250125023236.png]]

• אם אנחנו רוצים למשל שעון אדום במרכז הטרמינל בכל פעם שה-Prompt מדפיס, נגדיר את PS1 ככה: PS1="\[\033[s\033[0;0H\033[0;41m\033[K\033[1;33m\t\033[0m\033[u\]<\u@\h \W>\$ "

לשמור את ה-prompt אנחנו לא רוצים להגדיר אותו מחדש כל טרמינל, אז נוסיף ל-bash rc שלנו שתי שורות PS1="CUSTOM PROMPT" Export PS1 (בכל סשן מגדירים את המשתנה PS1, ועושים לו אקספורט כדי שכל תהליך שהטרמינל יריץ גם ישתמש בערך הזה של PS1 - כולל טרמינלים חדשים)

לעוד שנניגנז עם ה-prompt

מערכת

LANG

ה-ASCII character map שלנו כולל ערכים בטווח 0-255, כאשר זה כולל את כל התווים, אותיות אנגליות בשני הגדלים ושפה נוספת. להגדרת השפה שלנו (שקובעת מה היא השפה הנוספת) קוראים גם locale

$LANG מחזיק את הערך של ה-locale echo $LANG כדי לבדוק

locale כדי לראות הגדרות locale. ידפיס בין היתר את הערך של LANG export LANG=(locale) כדי לשנות את הערך של LANG

export LANG=POSIX כדי לחזור להתוויה הבסיסית של ASCII [[מילון BASH#Character Classes#|נועד כדי לכתוב טווחים ב-regex באופן מהימן]]

.Desktop files

To create a .desktop file for a program, you need to create a plain text file with specific fields that describe how the application should behave when launched. Here's a step-by-step guide:

1. Create the .desktop File

You can create a .desktop file anywhere (but for system-wide applications, it's usually located in /usr/share/applications/ or ~/.local/share/applications/ for a user-specific application).

• Open a text editor and create a new file, for example myapp.desktop.
• Save it with the .desktop extension.

2. Basic Structure of the .desktop File

Here’s a minimal structure for a .desktop file:

[Desktop Entry] Version=1.0 Name=My Application Comment=This is a custom application Exec=/path/to/application %f Icon=/path/to/icon.png Terminal=false Type=Application Categories=Utility;Development; MimeType=text/plain;

Explanation of the Fields:

• [Desktop Entry]: This is required and signifies the start of the entry.
• Version: The version of the .desktop file format (usually 1.0).
• Name: The name of the application as it will appear in the menu.
• Comment: A brief description of the application.
• Exec: The command to run the program. You can include placeholders (like %f for a file) if the program accepts them. Example: /usr/bin/myapp %f will open files passed to it.
• Icon: The path to the icon to be used for the application. You can use absolute paths or icons from system-wide directories.
• Terminal: Whether the program requires a terminal to run (true or false).
• Type: Usually Application for regular applications.
• Categories: A semicolon-separated list of categories that helps group the application in menus (e.g., Utility, Development).
• MimeType: Optional. Specifies which MIME types the application handles (e.g., text/plain).

3. Save the .desktop File

Save the file with the .desktop extension. For example, myapp.desktop.

4. Make the .desktop File Executable

You need to make the .desktop file executable in order for it to function correctly as a shortcut.

Run this command: chmod +x myapp.desktop

5. Move the .desktop File to the Applications Directory (Optional)

To make your application appear in the applications menu, move the .desktop file to one of the following directories:

• User-specific (just for your user):

  mv myapp.desktop ~/.local/share/applications/

• System-wide (for all users):

  sudo mv myapp.desktop /usr/share/applications/

6. Refresh the Application Menu

פאת'ים חשובים

/usr/share/icons - חבילות אייקונים בגנום 47 /var/lib/flatpak/exports/share/icons/ אייקונים של flatpak /usr/share/themes - gtk themes ~/.var/app/app.zen_browser.zen/.zen zen browser flatpak profile dir path

• לזכור, רק בווינדוז משתמשים ב-backslash!