Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

I did something sorta dumb in Linux

Renzatic

Renzatic

Suspended
Original poster
Aug 3, 2011
9,561
10,118
Gramps, what the hell am I paying you for?
It's a long story I'm not about to get into unless I absolutely have to, though I will shoot one quick question that might help me out.

My terminal skills are about weak, and I need a rough idea of what this script does...

#!/bin/bash
cp -rp -t ~/ .config/ .icons/ ; cd .. ; rm -fr dropbox-integration/

I have an idea of what it does, and I think I've fixed it, but if I haven't, knowing what this does will help me out tremendously.

...yeah, I shouldn't do anything in Linux unless I know exactly what it does. The one downside to it compared to OSX and Windows is that it's not exactly stupid-proof.

edit: okay, I fixed the problem, but I'd still like to know what the script does exactly. I know it's copying and replacing files and folders from one location to another inside my home folder, but the syntax is about confusing.
 
Last edited:
cp is the copy bin
-r means to recursively go into every subfolder, not just the top level
-p means not to go into symlinks (shortcuts)
-t means this is where all the following things will be copied to (In this case, your home directory)

So .config and .icon folders with all stuff except stuff from shortcuts wil be copied to your home directory.

; means separation between commands.

cd .. Means to go to the higher level directory from where you are launching this command (go up)

Rm is the remove bin
-r means recursive as above
-f means to force it to remove it without asking warnings/confirmation

And dropbox-integration is the directory that is forcefully being deleted
 
Renzatic said:
Thanks. It seems pretty straightforward when it's spelled out like that.

Though I do have one small question, what exactly are bins? It seems like a "storage container" for action from the way you're explaining it, but I want to be sure.
Click to expand...

It's a shorthand way of saying "binary". So cp is the copy tool binary, rm is the deletion tool binary, etc.

The /bin, /sbin, /usr/bin, and /usr/sbin directories are named as such because they directories where your binaries are stored.
 
556fmjoe said:
Snip
Click to expand...

Gotcha, thanks. I moved my /Home folder to another partitition today, and I'm discovering that I can just about follow along with the terminal commands, and understand what they were doing. I'd hardly call myself a pro just yet, but I feel like I'm starting to learn how it all works.

The only thing that still gives me an issue in Linux is where my programs go when I install them. I believe that usr/bin is the equivalent of ~/Library in OSX, or the Program Files folder in Windows, but the thing is, not all my random programs seem to go there. Sometimes they'll go there, sometimes they'll go into my home folder, or sometimes they'll go into any of the other various bin or sbin folders scattered throughout.

Once I'm able to predict where they go, and maybe even control them so I'll know where they're grouped, I'll feel like I have a much, much better handle on Linux. Right now though, it takes me forever to find an executable if I need it.
 
Renzatic said:
Gotcha, thanks. I moved my /Home folder to another partitition today, and I'm discovering that I can just about follow along with the terminal commands, and understand what they were doing. I'd hardly call myself a pro just yet, but I feel like I'm starting to learn how it all works.

The only thing that still gives me an issue in Linux is where my programs go when I install them. I believe that usr/bin is the equivalent of ~/Library in OSX, or the Program Files folder in Windows, but the thing is, not all my random programs seem to go there. Sometimes they'll go there, sometimes they'll go into my home folder, or sometimes they'll go into any of the other various bin or sbin folders scattered throughout.

Once I'm able to predict where they go, and maybe even control them so I'll know where they're grouped, I'll feel like I have a much, much better handle on Linux. Right now though, it takes me forever to find an executable if I need it.
Click to expand...



The various /bin directories can get confusing, so here's a general rundown of what each does (it varies by distribution)

/sbin: Binaries needed for booting, or that you might need for maintenance or administrative tasks when no other filesystems are mounted. If you had some sort of failure, booted to single user mode, and didn't mount any partitions, you should have the binaries in /sbin available. These binaries are limited to tools you'll need to boot, repair, or restore the system. These executables are also not usually in the PATH variable of a regular, non-root user.

/bin: Kind of a general use executable directory for the system's operation, but not focused on maintenance. It includes essential binaries necessary for operating the system normally. It also includes the shells installed on the machine. These executables are to be used by both root and non-root users.

/usr/sbin: Contains system binaries not needed until after the /usr directory is mounted (i.e. after booting). It also contains a few daemons and some administrative tools.

/usr/bin: Normal applications that are included with the OS and designed to be run by normal users. This includes most user applications. It also includes user installed applications here, though not in every Linux (or other Unix like) system. On my Mint laptop, if you install Firefox, you'll see /usr/bin/firefox here.

/usr/local/sbin: Locally compiled or installed system binaries that aren't needed until after booting. Kind of like /usr/sbin, but for local users.

/usr/local/bin: Local binaries, often times installed by the user. This directory may or may not be heavily used by your distribution, and it varies across Unix like systems. On OpenBSD, just about everything you install goes in /usr/local/bin. On many Linux systems, locally installed applications will simply go to /usr/bin instead.


Generally, I store programs and shell scripts I write in /usr/local/bin to avoid confusion and to make them easy to find.


You can get a much better explanation of these directories and every other directory here (and anything that FHS says trumps what I said, since they're the experts): http://www.pathname.com/fhs/pub/fhs-2.3.html
 
556fmjoe said:
snip
Click to expand...

Thanks again. I've read through about a quarter of it, and...yeah, it's pretty dry and boring, but very informative just the same.

Though it still doesn't answer my question of how to find application locations quickly and easily. Though I understand how it's supposed to go, some apps don't go where you think they'd go, and are ultimately up to the whims of a developer. Is there a way you can look up its location from the terminal?

And on top of that, is there a way to look up the name of an app in the terminal without knowing the full thing? For example, if I wanted to find Chrome, I wouldn't necessarily be able to just type up "sudo chrome" to launch it from the terminal, because it's not just called "chrome" there. It could be something like "google-chrome-x86-64", or "google-chrome-canary-developer-preview-38". Is there a way to get a full name for an app by looking up its partial name?
 
If you're not comfortable with UNIX and not absolutely sure what a command is doing I wouldn't recommend using Terminal, especially when rm (remove/delete) commands are involved. It can be a very efficient and quick way to do some advanced things that OS X doesn't really support in the GUI, especially things like recursive searching and copying/deleting/moving/renaming etc, but even the best of us can make mistakes from time to time.

Having said that (and got the obligatory disclaimer out of the way), it's definitely a great skill to have. I recommend trying to understand exactly what the command is doing and building it yourself rather than copy and pasting from the internet, which you seem to be doing.

UNIX isn't a very friendly environment (operating system) and the manual pages are pretty atrocious by and large. But the binaries (commands) are generally very efficient and powerful, especially when used together in complex ways with stdins/outs and pipes.
 
Trust me, if it came right down to it, I'd rather use the GUI for 99.9% of my daily tasks, and Linux has finally become more than good enough to do just that. You're not forced to use the terminal nearly as much these days. Beyond adding PPAs, and a few mass file moves, I can't think of a situation where it's easier just to hit up the terminal.

But...

The Linux and Unix community have a strong history of doing everything from the CLI, and most people telling you how to do things will do so from there. Case in point, when I moved my /home folder to another partition, it had me do everything, resizing, reformatting to ext4, and all from the terminal or by editing text files. The first part I could've done with a few clicks from Gparted or even Disks (which is what I ended up doing), but they really want to drill the terminal into your head. That's real 'nix, they'll say, do it right.

So I figured if I'm gonna be taught that way, I might as well learn exactly what I'm doing, rather than copy/pasting random esoteric strings of commands, and hoping for the best.

Plus I'll run into situations like I had above where I grab a random tweak off the internet, and it does something weird. Like I wanted to give my Dropbox folder better integration with Nautilus, but I grabbed the wrong package, and it ended up turning my desktop into a giant Dropbox folder. I ended up fixing it by going through the folder, reading what went where, and changing it back to how it was before by hand. I ended up learning something by having to fix it all, but I could've saved myself even that effort if I knew exactly what I was doing beforehand.

...cuz next time, I might not be so lucky. O_0
 
Renzatic said:
Thanks again. I've read through about a quarter of it, and...yeah, it's pretty dry and boring, but very informative just the same.

Though it still doesn't answer my question of how to find application locations quickly and easily. Though I understand how it's supposed to go, some apps don't go where you think they'd go, and are ultimately up to the whims of a developer. Is there a way you can look up its location from the terminal?

And on top of that, is there a way to look up the name of an app in the terminal without knowing the full thing? For example, if I wanted to find Chrome, I wouldn't necessarily be able to just type up "sudo chrome" to launch it from the terminal, because it's not just called "chrome" there. It could be something like "google-chrome-x86-64", or "google-chrome-canary-developer-preview-38". Is there a way to get a full name for an app by looking up its partial name?
Click to expand...

Are you just trying to find the name of the executable, or are you trying to find the full path? The latter should not be necessary just to execute it most of the time, unless you need it for a shell script.

If you wanted to find Chrome's executable, you could do something like

Code: 
ls /usr/bin | grep chrome

This will show you all the executables in /usr/bin with "chrome" in their name, even if they have something else in the name too like "chrome-browser" or "google-chrome". You can obviously replace /usr/bin with /bin, /sbin, etc as needed, but in Linux, you're probably better off looking in /usr/bin first.
 
556fmjoe said:
Snip
Click to expand...

Thanks. That'll help out tremendously. Though I discovered something even simpler, and more in line with what I had in mind...

The Locate Command.

...and that's how it should be done. Right now, my only problem with it is that if you don't know the exact name of the file you're trying to locate, the results can be really, really, really way too verbose.
 
Renzatic said:
Thanks. That'll help out tremendously. Though I discovered something even simpler, and more in line with what I had in mind...

The Locate Command.

...and that's how it should be done. Right now, my only problem with it is that if you don't know the exact name of the file you're trying to locate, the results can be really, really, really way too verbose.
Click to expand...

Try this to trim it down

Code: 
locate chrome | grep bin

That will leave you with only the paths that have "bin" somewhere in them.
 
Renzatic said:
And on top of that, is there a way to look up the name of an app in the terminal without knowing the full thing? For example, if I wanted to find Chrome, I wouldn't necessarily be able to just type up "sudo chrome" to launch it from the terminal, because it's not just called "chrome" there. It could be something like "google-chrome-x86-64", or "google-chrome-canary-developer-preview-38". Is there a way to get a full name for an app by looking up its partial name?
Click to expand...

Assuming you know how the command begins, the easiest way is using tab completion:
tldp.org/LDP/abs/html/tabexpansion.html

To get a list of commands starting with "goog" I would do the following
# goog <tab><tab>
List of commands here.

This will not work if you are prefixing a command with sudo, or if the file or directory is not in your $PATH.

Failing that, I would generally prefer the "find" command over "locate" - it is much more powerful and flexible and its worth learning.
 
Alright, people. I'm going for my nerd badge of honor here, and am now attempting to compile a program from source.

Everything's been going fairly smooth when it comes to installing programs. Mostly I hit up the software center or Steam for most of my applications, occasionally I'll add a PPA and install through the terminal, even more occasionally I'll unzip a binary from a tarball, but nothing too complicated.

...until now.

See, I gotta have my PS1 emulator. And the one PS1 emulator that works best on Linux only provides the source code for the latest version. Absolute pain in the ass, to be sure, but I figured I could handle it. I read through a few readmes, install some random stuff, and...it hasn't been fun, but it seemed pretty straightforward. Until I ran into this one problem I can't seem to find a way to work around.

Basically, it's having trouble compiling source code from a subdirectory, and I apparently need to enable subdir-objects to get it to work. Hell if I know how to do that, though. Since a picture is worth a thousand words, I'll just post a screenshot, and hope you all can gleam some info from it.

Here.

Not an easy question, I know.
 
SlCKB0Y said:
I found this...
Click to expand...

I feel no shame in admitting that about 99.9% of that was entirely over my head. :p

I did discover that there's a generic readme file buried within the source code that gives semi-detailed instructions on how to compile. It seems easy enough, and apparently the code's been packaged so it builds with very little effort.

But when I try to ./configure; make; make install. It gives me a syntax error, which I'll show you below. I did go through the configure file to see what was up, but...eh, I don't know what I'm doing, so I obviously don't know what needs changing even while I'm looking right at it.

I do know that this package has been compiled successfully before by apparently thousands of people. It's just not compiling for me.

Here
 
You cannot find a already compiled version of the PS1 emulator ? Troubleshooting make on a forum could be quite a challenge, IMO.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back