locate command on Ubuntu 14.04

[Rene Thomas]

Hello all Linuxers who are not so advanced in the knowledge as to be unable to communicate with someone with little old me, who has such rudimentary knowledge he doesn't know what a tarball is.

I am stuck using the locate command, which I was learning about from a tutorial on youtube.

It didn't explain why I would have to update the database first, but I used the updated command, added a superuser permission, eg. sudo updatedb .

As expected, after I had put in my password I received no output, just the normal command line prompt. That happened on the video too, so I assume the database got updated, especially because the delay after issuing the command was so long.

Next, I attempted to locate a file which I had created in my home folder, being navigated to my home folder at the time. However, the locate command also came back with no output, whether I put inverted commas around the file name or not.

I am using Ubuntu 14.04 with the standard bash terminal. Everything else seems to work fine (except the xsane scanner interface, but that's another story.

Can any of you good people suggest, in language comprehensible to a sub-newbie, why I can't locate the file?

 

[Mitt Green]

locate reads databases, that are prepared by updatedb, so every time a new file is made, you have to run the latter.

I would recommend using find, which is a standard Unix utility, unlike locate. It is slower, but does not require updating the database. See more precise descriptions in their man pages.

 

[Rene Thomas]

Thank you, Mitt Green. I will use find instead. Even I can do that Android I will one day be capable of comprehending the man pages.
Or, in the primitive Androidese of my reconditioned tablet, "utiM ,uoy kTMitGreenGreen. I will use "

 

[unixfish]

If you are looking for a command that is in your path (ie you can type the command and it runs), the "type" command is what you want. For instance, if you want to know where the "ls" command is run from:

$ type ls
ls is /usr/bin/ls
$​

This only works for where your path is set. This command is nice to see if there are multiple versions of a command in different directories to see which one is "found first". Years ago, I had a user ask me to run a command as root for him. Well, it seems he had a local copy of that command which gave himself root privileges if I had run it - the type command would have shown that. (He was assuming I had the current directory in my path - which of course I did not).

I'm not sure exactly what you're after, so I'm just throwing out some other ideas. So much like Linux - many ways to do the same thing.

 

[RowBat]

If you are trying to find a file or folder do as Matt said. Also a tarball is an archived folder.

 

[Rene Thomas]

Thanks for those tips

A tarball is nothing like what I imagined it to be, then.

So much is being revealed to me about computing, such as the similarities (or identity even) between files and commands.

Some of it I can vaguely remember from being a child with a new 8-bit toy, but the conceptual stuff (that to tell the computer to do something you have to use chunks of its own memory to instruct it) smacks more of what I learned studying philosophy, like the way of seeing "things" as "processes ".

I realised today, unixfish, the shift in usage of the term "of course" to mean something aslant to "obviously" in modern English, because it isn't obvious to me why you didn't have that directory in your path.

The whole path section went a bit over my head, but I reckon that for once I can figure that one out by myself, with the help of that little command you showed me which seems so useful, ie. type

 

[unixfish]

Ah! Good point!

Having the current directory (./) in the path is a security issue. Like in the example, if someone "leaves" a program in a common folder, like /tmp, and you are cleaning up old files, you could run "some else's" version of a command that can do bad things. Sometimes a user can get lazy and put ./ in the front of a path so they don't have to type command paths. Actually, shortening your path to the "basics" is a better thing to do - it keeps you from running the wrong version of a command.

Yes, I get it - it's really inconvenient when you are learning. But once you get the hang of it, you will be better off.

OK, I'm done "preaching"!

 

[Rene Thomas]

But I like preaching!

Thanks, unixfish

 

[RowBat]

Rene Thomas,
I'd recommend reading up on environment variables.

Additionally,
Shannon Morse from Hak5 (YouTube or hak5.org) has a bunch of intro videos done well and Nixie Pixel also used to do a lot of intro videos that were okay. There are obviously others too but there's I know are decent.

 

[Rene Thomas]

Thank you, RowBat.

That gives me plenty to be going on with.



I have watched a couple of videos by Nixie Pixel. It looks like her success as a youtube presenter is largely due to her conventional prettiness .

I am a bit wary of some of her content and that of Hak5, because as far as possible I try to avoid politicised content, being someone who is pretty easily inffluenced in ideological terms.

Reading about environment variables on the 'net generally does appear to be a good next stop for me as far as learning Linux goes.

Rowbat, like the other members of the Linux-org community, you are worth your weight in devices