----BEGIN CLASS---- [14:00] #startclass [14:00] jasonbraganza: i am trying to fix the issue. [14:00] Roll Call [14:00] Jason Braganza [14:00] shivam soni [14:00] aritra [14:00] Saransh [14:01] nagarajan [14:02] kiyo [14:02] looks like a fairly full house [14:02] good evening people [14:02] so LYM. [14:03] how many of you read the chapters given? [14:03] and how many of you consider yourselves fairly proficient at the command line? [14:03] me but not 3rd ch file system [14:03] Yes I am proficient 8D [14:04] I read the 3 chapters but i gues i skimmed the linux filesystem [14:04] guess* [14:04] not proficient, but can do basic things by myself. [14:05] skimmed through LFS [14:05] shivam, specbeck ? [14:06] me and somewhat struggling [14:06] so alright. [14:06] let’s tackle the FHS first. there really isn’t much i have to add there [14:06] i have read two chapters, i can do basic things using cmd. [14:06] it’s a living document. [14:07] best to bookmark it and keep referring to it. [14:07] because even today, when i keep wondering *where* stuff could be [14:08] the FHS gives me the most common locations i can find things in [14:08] and also the new places stuff keeps moving to. [14:09] it lags a bit behind the ways things currently are. (like Mint and Ubuntu are moving to putting most thing into /usr/sbin and /usr/bin instead of the old /sbin and /bin) [14:09] but it catches up sooner or later [14:10] and it is a good way to find out how Linux distributions choose to store stuff. mostly in a very standardised manner now [14:11] the wild west days of the 90s where every distribution copied some unix / posix variant they were influenced by, and had very different ways of operating are long gone [14:11] the evolving FHS has helped keep stuff sane. [14:12] so if you move from Fedora to Debian to Arch or its variants, you can trust that you will find the basic stuff in places that lie within your muscle memory [14:12] bash for e.g. i know i will find in /usr/bin (or in the old times in /bin) [14:13] so i would suggest that you do a deep dive at least once. so that you get a good idea of where stuff lien [14:13] for e.g. i don’t care what program it is, the first place i look for its logs is in /var/log [14:14] 99% of the time it is in that directory or some subdirectory within it. i never have to think [14:14] makes administering the machine much easier. [14:14] or guessing at where to find stuff or a foreign machine more predictable. [14:15] will break for a min or two. and wait for questions you have on the FHS [14:16] do we know why we moved from /bin to /usr/bin [14:17] i noticed everything i install manually sits in usr/local/bin. This is fine but it would be good to know why. [14:17] kiyo, i don’t. i should look that up. [14:17] all i know is that it is something that is happening :) [14:18] i'm fine with this too. :) [14:18] kiyo, found it. i knew i read it some place. here - https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ [14:18] thanks! [14:19] other folks? questions? or should we move on? [14:20] yes, will ask afterwards, need some time to dwell in [14:20] yes, sure we can move on. [14:21] shivam, specbeck ? [14:21] we can move ahead [14:21] yes need time to deep dive so will ask afterwards [14:21] shivam, specbeck this is the second time i am pinging both of you. are you folks around? [14:22] i don't have any question, we can move ahead. [14:22] I am [14:22] Yes, need to explore more, before asking anything [14:22] you folks, be a little more responisve ok? [14:22] *responsive [14:22] i cannot be shouting into the void alone here [14:22] jasonbraganza, got it [14:23] ok have all of you read the two command chapters? [14:23] yes [14:23] yes [14:23] yes [14:23] yes [14:23] this is more like it [14:23] thank you [14:23] yes [14:23] yes already been using linux since last year, plus find some interesting commands in lym docs [14:24] s / find / found [14:24] so other than kiyo, i am assuming that you folks are new(ish) to the command line? [14:24] yes [14:24] yes, started last week [14:24] with that in mind, here’s the thing. the big difference [14:24] no [14:25] the command line is a way of interfacing with your computer [14:25] have spent some time with it, but mostly preferred GUI [14:25] once upon a time it was the only way. [14:25] before the command line era, we’d just toggle switches straight on the machine [14:26] or give it punched cards, so that the computer could read the pattern and process it [14:26] and then came the interactive command line [14:26] which let you give a command to the computer [14:27] and have it respond back (near instantaneously) [14:27] and that is what we used [14:27] until the mass spread of the GUI with the Mac and Windows in the late 80s [14:28] that is the new way to interface with the computer now [14:28] and it’s a lot more pleasant [14:28] tomorrow there might be new ways to interface with the computer [14:29] sound is almost mainstream now [14:29] Alexa, Ok Google, Siri are all only a call away [14:29] even AR is just around the corner [14:30] things are getting ever more convenient [14:30] so why do we use the command line still? [14:30] one. because these new forms of interfacing are still locked down. and there is no open alternative [14:31] two. performance. it might be a tad hard in the beginning to communicate with the computer using text [14:31] in the beginning [14:31] but as you get used to it. [14:32] you’ll see the myriad ways in which the command line makes things so much more convenient [14:32] how many of ya’ll have seen those complex install commands that you copy paste in to install stuff? [14:32] me [14:32] me [14:32] yes [14:33] same as with tor key authentication [14:33] me [14:33] yes [14:33] you can with time and practice just break it down [14:33] into smaller commands [14:33] yes [14:34] and you will see that it is all just built up piece by piece [14:34] curl -L https://github.com/pyenv/pyenv-installer/raw/master/bin/pyenv-installer | bash [14:35] this is the command pyenv uses to install itself [14:35] it basically is just two things [14:35] one is the curl command [14:35] where i tell curl to download something from that url i give it [14:36] and curl then gets a bash script from there [14:36] and then this [14:36] | [14:36] thing [14:36] can you see it? in that command? [14:36] yes [14:36] yes [14:37] yes [14:37] yes [14:37] yes [14:37] so that is an operator that tell us that the output of the curl command? just “pipe” it … like water in a pipeline … pipe it through to bash [14:37] which is the command at the end [14:38] bash takes that script and begins executing whatever is in that line by line [14:38] you can see the contents of that script here - https://github.com/pyenv/pyenv-installer/blob/master/bin/pyenv-installer [14:39] which brings us to the magic of the command line [14:39] i can just take those commands and type it in one by one [14:39] and get pyenv installed [14:39] or put it into a script [14:39] and then like you saw, with the various operators that the shell will give us [14:39] just let the computer do the hard work [14:40] so the command line does not mean by heart these 10 esoteric commands [14:40] the command line ethos basically is [14:40] learn the commands [14:40] and then learn to chain them together [14:40] and then learn to automate it all, so you don’t have to type or do the same things over and ohver and over [14:41] and that is a lovely long journey [14:41] so the command line interface? that is not linux specific [14:41] There was DOS which was command line orientde [14:41] it now hides in windows as the command prompt [14:42] and newer more improved interface (for windows) would be Powershell [14:42] the original Mac OS had no commandline [14:42] which hampered os automation a lot [14:43] which is why we all rejoiced when OS X with it’s FreeBSD underpinnings brought bash to the Mac [14:43] We've always had a command line :) [14:43] we as in linux [14:44] Digital’s VMS was a command line interface or IBM’s OS/2 had a command shell too [14:44] so no matter what the os [14:44] every one has this interface [14:44] where we type in commands to the machine [14:44] and then automate them :) [14:45] i have a commandline daemon called espanso running on my machine [14:45] which is a text expansion engine [14:45] which saves me a lot of typing [14:45] if i do :njx, it automatically replaces that with Jason Braganza [14:46] the only reason i do espanso is because it expands into gui windows too [14:46] but if i was in the command line environment, even bash aliases do the same thing [14:46] i can just assign something to an alias andthen i save so much time on the command line [14:47] alias ec='emacsclient -create-frame --no-wait --alternate-editor=""' [14:47] this is a line from my bash aliases [14:47] rather than type emacsclient -create-frame --no-wait --alternate-editor="" [14:47] everytime i want to launch an emacs client window [14:47] i just type ec [14:47] and boom [14:48] pigx [14:48] is just an alias to ssh ubuntu@192.168.0.80 [14:48] that is my pi [14:49] so i never have to keep typing the whole thing into my command line [14:49] the next step then [14:49] is to just take yourself out of the equation [14:49] from aliases you type [14:49] move on to scripts that the machine can run [14:49] just gimme a min [14:51] found it [14:51] this is a file called bpub.sh [14:51] on my little vm online [14:51] #!/usr/bin/env bash [14:51] #source /home/user/.profile [14:51] #source /home/user/.bashrc [14:51] cd /home/user/blogs/hugo [14:52] /usr/local/bin/hugo && rsync -avz --delete public/ webuser@127.0.0.1:/var/www/hugo [14:52] so i can just type the last two lines [14:52] and it will rebuild and publish my blog for me [14:52] but who wants to remember all that? [14:52] i just type in bpub.sh [14:53] and the computer does it all [14:53] and then [14:53] i can tell the computer [14:53] take this script [14:53] and run it thrice a day (with something called a cron job) [14:53] and now i have removed myself from this whole publishing blog business [14:54] all i do is write a md file and put it in that folder [14:54] and the post gets published on the next run [14:54] and if i want to do it immediately, i can just go run that script myself [14:54] fun so far? [14:54] nice [14:55] so nice [14:55] yeah [14:55] great [14:55] yes [14:55] yes [14:55] yes. [14:55] so that in a nutshell is your ethos [14:55] learn the commands, byheart the most common ones. [14:56] but your goal is never to mug them up. the goal isto have a *huge* toolkit of commands handy to automate and script and run [14:56] and that is a fun thing to do [14:56] the next step up is just your computer now talking to other computers [14:57] that’s what github hooks are at a base level. or docker files. [14:57] so little computer reads some yaml you wrote. or an action you published [14:57] and then runs through those commands [14:59] and then takes this code from this repo and that runner from that docker repo and then mashes them all together to compile something and test something else and then another set of commands will tell it, oh this is a blog, push ithere or these are new releases of a program. create these artifacts [14:59] so from pecking ls at your keyboard, with time and experience you get to orchestrate machines to do your bidding [15:00] and the fun thing is, you get to decide what level you are comfortable with and where to stop [15:00] or what is needed at which level of your career [15:00] my objective this session was to open your eyes to the wonder that is the command line. [15:01] questions? [15:02] ! [15:02] next [15:02] nope till now, will ask once read and practice the commands in lym [15:03] ! [15:03] ! [15:03] Does the command line have some limitations too compared to the GUI or is it the other way round with CLI being dominant? [15:03] of course it does. [15:03] it is not as friendly, is it? :) [15:03] and in this day and age, it is the GUI that is dominant [15:03] Ooh yes :) [15:04] but as future programmersa and computer hackers, the command line should be *your* dominant interface when it comes to work [15:04] what service have you used for a little vm online? I have used aws but you end up paying for it even in free tier. [15:04] kiyo, i pay too :) [15:05] when i say little vm, i mean low powered (single core, 2gb or something like that) not free [15:05] next [15:05] you mentioned macOS not using command line in one of the versions, what were they using instead? [15:05] and kiyo use ! [15:05] ah! sorry! [15:06] mars, nothing really. it was hard to do stuff. later versions had something called Applescript which was uhm underpowered compared to what we can do :) [15:06] next [15:06] can you tell us what other things can be automated? that blog publishing one was amazing. What else you have automated? [15:06] ari0x, i am a lazy boy [15:06] if it can be automated, i do it :) [15:06] kiyo: sorry to interrupt, just sharing, there are some pubnix services which are free, you can use host blog or something or use their other services like bouncer etc [15:06] circuitlover, all that after the session :) [15:07] ok sure :) sorry [15:07] hang around and discuss this sort of stuff, instead of just vanishing like ghosts! [15:07] ok :) [15:07] ari0x, everyday at 12p a small script backups most of my config files into a dated folder [15:08] so if my emacs config (on the desktop) or an nginx config (on my server) gets corrupted or i manage to bungle things up [15:08] ! [15:08] i just go to one of those folders and bring back that copy [15:09] another script runs some analytics program on nginx logs and then generates web statistics and then puts it into a folder which then syncs to my desktop, so i can see how many visitors to my blog over time [15:10] another one watches a folder and then runs another script that posts anything that comes into it to twitter or the fediverse or both [15:11] ari0x, hope these are enough to make you want to do more :) [15:11] next [15:11] Is there a way to merge the CLI and the GUI together and have something that is user friendly along with the power of the CLI? [15:11] yes, that's so great. will surely explore more to automate stuff. [15:12] specbeck, no idea. but something that comes close is something that i call application launchers. check out ulauncher on linux or launchbar on macOS [15:12] next [15:12] alright [15:12] so one more small thing before i go [15:12] do all the commands please. practice them over and over. [15:12] i should probably workshop them with you here, but we are running out of time [15:14] so sometime later, if you folk are interested we can work through the commands in the chapters these are not complex [15:14] so you should be able to try these out and come ask questions in here [15:14] specbeck, ooh i remembered another one [15:14] gui wrappers around cli tools [15:15] so there are lots of gui frontends to mplayer or ffmpeg [15:15] which are cli tools [15:15] similarly all the modern cloud interfaces [15:16] you can drive them manually with the gui [15:16] and accomplish what you want by pointing and clicking and dragging [15:16] or use a program to talk to the api with a cli. and just *zip* through stuff :) [15:17] case in point. [15:17] i can just open an image and resize it [15:17] and another [15:17] and another [15:17] and another [15:17] or just write a script that tell imagemagick to resize the 4000 images i got back from my Nainital trip [15:17] :) [15:17] so where was i? [15:18] Alright, I see, thanks :D [15:18] aah one more small thing before i go [15:18] the heart of the interface [15:18] is something called the command processor [15:18] or the shell [15:18] it takes what you give it [15:18] and then tries to make sense of it [15:19] and then depending on what you tell it do stuff with it [15:19] so here’s the thing [15:19] or three things [15:19] internal commands [15:19] external programs [15:19] scripts [15:19] internal commands are commands that do not exist on the system [15:19] bash is the shell on my machine [15:20] and it has the capability to understand some stuff on its own [15:20] it does not have to look around for programs to do it [15:20] any of you have a command prompt / a terminal handy [15:20] ? [15:20] yes [15:21] do a `which ls` please and tell me where it is? [15:21] just type [15:21] which ls [15:21] and it will tell you where ls is on the machien [15:21] /usr/bin/ls [15:21] same - mine is /usr/bin/ls [15:21] same [15:21] so ls is a program which lies in /usr/bin [15:22] whenever you folks do an ls, then that is the program that is called [15:22] so since /usr merged to /bin, which you said before right ? [15:22] and then ls shows you the contents of that dirictory [15:22] mine is /usr/bin/ls [15:22] circuitlover, yea :) [15:22] now do [15:22] which cd [15:22] and tell me what shouws up [15:22] nothing comes [15:23] so it is internal command [15:23] ! [15:23] or which time [15:23] try which time [15:23] next [15:23] but mine says /usr/bin/cd [15:24] /usr/bin/time [15:24] what gnu pkg installs cd? is it the bash shell? [15:24] ari0x, what shell do you use? bash? [15:24] yes [15:24] so we see that in some cases there is a cd command [15:24] and in some cases there is not [15:24] in the cases there isn’t one, the cd command that you see is used [15:24] the orginial shell was something called sh [15:24] and that was pretty barebones [15:25] that had no cd support, so the cd you see was made to help then. [15:25] bash tries to use it’s internal cd as much as possibel [15:26] kiyo, i honestly don’t know :) i thought that was part of the shell :) [15:26] so bash has some commands that are internal as we saw [15:26] and the rest come with the system [15:27] in various places, which if you consult your os manual and the fhs doc, you should get a pretty good idea of what lies where [15:27] some more you will install yourselves, because the system cannot give you all you want. [15:27] so we apt install and dnf install and pull down more with curl and wget [15:28] and then finally we write scripts that combine them all to do the dance we want computer to perform for us :) [15:29] can you folk also do `echo $PATH` on your computers/ [15:29] ? [15:29] yes [15:29] that was not rhetorical, do it an tell me what it says XD [15:30] /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin [15:30] so you see these locations? [15:30] mine is: /home/ari/.nvm/versions/node/v16.16.0/bin:/home/ari/.local/bin:/home/ari/bin:/usr/lib64/ccache:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/var/lib/snapd/snap/bin [15:30] mine won't post. too long i think? [15:30] yes [15:30] kiyo, no matter :) [15:31] those are the places bash (or your favourite shell) will look for programs. and in that order. from left to right [15:31] in circuitlover’s case it will look first in /usr/local/sbin. [15:31] and if it does not find it there it will look in /usr/local/bin [15:31] /home/kiyo/.nvm/versions/node/v18.2.0/bin:/home/kiyo/kde/src/kdesrc-build:/home/kiyo/emsdk:/home/kiyo/emsdk/upstream/emscripten:/home/kiyo/emsdk/node/14.15.5_64bit/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin [15:31] /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin [15:31] ah needs a space [15:31] and if not there further down the path [15:32] so you get the idea [15:32] ? [15:32] yes got it [15:32] it looks from left to right. [15:32] got it [15:32] we can add user scripts path to it, so it will run our scripts directly just by typing name right ? [15:33] so what happens if i have a program in /usr/local/sbin and also in /usr/bin in circuitlover's case? what happens if i have copies of ls in both locations? [15:33] circuitlover, use ! :) [15:33] sorry [15:33] ! [15:33] next [15:33] we can add user scripts path to it, so it will run our scripts directly just by typing name right ? [15:34] first answer my question folks, then i’ll tackle circuitlover’s :) [15:34] i think it will run as per the priority order like left to right [15:34] whatever comes first [15:35] bingo :) [15:35] yes, I think it will run /usr/local/sbin first, as it checks left to right [15:35] so in cds case. if it is an internal command as well as in a location? what happens? [15:35] internal first [15:35] yes internal first [15:36] bingo :) you folk seem to have a pretty good handle on this now. [15:36] and circuitlover yes, once you add your script locations to your path, or put your scripts in a location that already is in the path, we can just run them :) [15:36] ok, thank you [15:36] circuitlover, caveat, make sure you mark them as executable first :) how to do that? you figure out and tell me :) [15:37] chmod command [15:37] with that i think we can call it a night. [15:37] circuitlover hurrah :) [15:37] questions people? [15:38] no [15:38] no [15:38] only the two of you are left? [15:38] no [15:38] no [15:38] 4 [15:38] Wifi went out in between [15:39] :( [15:39] no [15:39]