Newbie trying to understand command instructions.

jdgriff80 · 11-23-2011, 11:34 AM

Hi,
I am trying to find out how to use some of the linux commands. I am trying to find out the path to gparted so I may use it. I am aware of the 'find' command but I do not get along with the information I receive from 'find --help'. Is there a better explanation somewhere that you can point me toward or maybe a better command.

Thanks
jdgriff80

Telengard · 11-23-2011, 11:47 AM

It should not be necessary to know the full path to a program to invoke it. If gparted is properly installed on your system then it (or a symlink to it) should already be in one of the directories on your path. You can show which directories are on your path like so:

Code:

echo $PATH

The path value is colon delimited.

If you want to read the documentation for find then use this command:

Code:

man find

Use the Up/Down arrow keys to navigate the manpage. Press the q key to exit back to the command prompt when you are done reading.

If you are using GNU Find, the full documentation is available on the web:

http://www.gnu.org/software/findutils/manual/find.html

The GNU Find documentation may also be installed on your system. If so, you can read it with this command:

Code:

info find

Navigate or quit from the info program similarly to man

Another command used to find files is locate. You can read the manpage with this command.

Code:

man locate

If you are using GNU Locate then the documentation is in the web page linked above, with GNU Findutils.

HTH

ukiuki · 11-23-2011, 11:53 AM

Hi the following thread might help you out: How to learn Linux?

Regards

johnsfine · 11-23-2011, 01:12 PM

Quote:

Originally Posted by Telengard

It should not be necessary to know the full path to a program to invoke it. If gparted is properly installed on your system then it (or a symlink to it) should already be in one of the directories on your path.

I have used a few distributions in which /usr/sbin isn't in the path unless you login as root and isn't even in the path if you su to root, so using sudo or su to get the ability to use gparted still leaves it off the path, so you need to know it is in /usr/sbin (on those systems).

Quote:

If you want to read the documentation for find then use this command:

Code:

man find

man find is a great example of what is wrong with Linux. You have an incredibly powerful flexible command that can do all sorts of things a beginner can't begin to understand. It also does an important fairly basic operation that a beginner needs. Now try to dig through all the advanced detail of man find to get any clue how to do that basic operation. It is pretty much hopeless.

For some tools the only reasonable way to start the description would be with a basic example. Failing to do so makes the man page garbage.

Quote:

If you are using GNU Find, the full documentation is available on the web:

http://www.gnu.org/software/findutils/manual/find.html

Still terrible, but it has a reasonable example early enough to be considered usable documentation.

So I adjusted that example to construct the command

Code:

find / -name 'gparted' -print

That probably gave me the output I wanted buried somewhere among all the thousands of
find: /someDirectoryPath: Permission denied
messages. So I went back to the documentation to look for the option to have it only tell me what it found and not where it failed to look. Couldn't find that option. As with most of the times I've ever tried find, I failed. I'm a half way competent Linux user. This has to be even worse for beginners.

I'm all for teach someone to fish rather than give them a fish. But telling a beginner to go fish in find documentation is too cruel. If you don't want to tell them exactly how to use find for the current task, don't tell them to use find at all.

Telengard · 11-23-2011, 01:54 PM

Quote:

Originally Posted by johnsfine

I have used a few distributions in which /usr/sbin isn't in the path unless you login as root and isn't even in the path if you su to root, so using sudo or su to get the ability to use gparted still leaves it off the path, so you need to know it is in /usr/sbin (on those systems).

Great point! I totally neglected to consider such a case.

I do agree that manpages tend not to be newbie-friendly. That's why I also linked to the more complete GNU Findutils documentation. In most cases the GNU documentation is more descriptive than manpages.

Quote:

I'm all for teach someone to fish rather than give them a fish. But telling a beginner to go fish in find documentation is too cruel. If you don't want to tell them exactly how to use find for the current task, don't tell them to use find at all.

jdgriff80 specifically asked for better documentation for find. I think I provided exactly that. You could argue that a hand-holding tutorial would have been more appropriate for newbies, and I might be inclined to agree.

Thanks for your honest critique of my response to jdgriff80's help request. I accept your advice in the spirit it was intended. Feel free to PM me for more discussion if you like.

johnsfine · 11-23-2011, 02:34 PM

Quote:

Originally Posted by Telengard

Thanks for your honest critique of my response to jdgriff80's help request. I accept your advice in the spirit it was intended. Feel free to PM me for more discussion if you like.

Sorry, I was too harsh. Trying to use find always puts me in a bad mood. Slow commands are painful; Badly documented commands are worse; But the combination of slow and badly documented goes far beyond the sum of the two problems.

I expect the OP doesn't have big parts of his directory tree mounted via NFS, so find will run faster with fewer error messages than it does for me.

I expect there is a better way (I'm claiming half way competent at Linux, not anywhere near half way competent at find) but what worked for me (after I calmed down from the failure reported earlier) is

Code:

find / -name 'gparted' -print 2>/dev/null

That says to find things named gparted searching recursively from the root of the directory tree but throw away any error messages along the way. Throwing away all error messages is a bit of a big gun to shoot at the "Permission denied" messages that I don't want to see. But as a half way competent Linux user, it was the only gun I had handy.

Telengard · 11-23-2011, 04:13 PM

Quote:

Originally Posted by johnsfine

Sorry, I was too harsh.

No need to apologize , friend. I find honesty difficult to condemn.

When searching for files by name, locate is usually preferable to find. Depending on your system and your query, locate can be easier to invoke, faster to complete, and return more sensible results.

find

searches the specified directory hierarchies in realtime
matches files using criteria defined with a series of conditional constructs (a simple scripting language of sorts)
accepts either simple patterns (as in the shell) or regular expressions
criteria may include names, types, times, permissions, ownership, and more
directly invokes commands to process matched files

locate

searches a database of filenames which is usually updated on schedule through cron
only matches filenames because no other metadata is stored in the database
accepts either simple patterns (as in the shell) or regular expressions

So if you don't want all those errors and warnings you get from find / -name blah, then try instead locate blah. Just remember that any new files since the last database update won't be found by locate unless you first force a database update. You may also need to configure the update program to add new filesystems to the database.

Examples for Ubuntu using mlocate:

Code:

# find a file by exact name (case sensitive)
$ locate -b '\parted'
/sbin/parted
/usr/share/doc/parted

# this fails because new_file isn't in the database
$ sudo touch /new_file
$ locate -b '\new_file'

# force database update
$ sudo updatedb
$ locate -b '\new_file'
/new_file

# search by regular expression
$ locate --regex '.*new_file$'
/new_file

If I were to apply locate to the OP, I'd use something like this.

Code:

$ sudo updatedb
$ locate -b '\gparted'

Please understand that while those commands work on my system, I have no knowledge of the configuration of anyone else's system. I don't know whether locate is even installed, or how it is configured.

If I wanted to use find, I'd want to narrow down the directory hierarchies to search. This means knowing something about the filesystem organization.

Code:

$ find /{{s,}bin,usr,opt} -name 'gparted'

This works on my system, but I don't know about any other system.

Now that I've written all of this, maybe I've gone a bit overboard. Anyway, I hope it addresses OP's need more directly than my first response.

jdgriff80 · 12-01-2011, 02:18 PM

Hi all,
I am sorry to be so late to thank everyone for their input to my recent request, so "Thank you,thank you". I used a lot of the information offered and now am on my way to a better understanding of the Linux system. I have also found several forums that are filled with information. I also have been able to install a networked printer. See you around the Forum.
Don

Telengard · 12-01-2011, 02:33 PM

Sure thing, Don; glad to be able to help.

craigevil · 12-01-2011, 03:22 PM

LinuxCommand.org: Learn the Linux command line. Write shell scripts. - http://linuxcommand.org/

frankbell · 12-01-2011, 08:56 PM

I'd like to add whereis to the useful commands for finding stuff.

It returns only the binary, man page, and sources of the target. It excludes other types of files, such as documents and libraries.

chrism01 · 12-02-2011, 12:18 AM

If its a program and its in your $PATH, then

Code:

which cmd_name

works as well.

Telengard · 12-02-2011, 02:18 PM

Quote:

Originally Posted by chrism01

Code:

which cmd_name

If Bash is your shell then you can also use type.

Code:

$ type -a which
which is /usr/bin/which
which is /bin/which

VDP76 · 12-03-2011, 07:02 PM

hi guys,

what about this!?

Code:

whereis cmd_name

It is a direct way to locate where an application, its source and documentation are...here it is an example...

Code:

user@linux:~$ whereis cheese
cheese: /usr/bin/cheese /usr/lib/cheese /usr/share/cheese /usr/share/man/man1/cheese.1.gz
user@linux:~$

cheers