Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 4 years ago.
Improve this question
I am working through this resource: https://cmdchallenge.com
On the following challenge: https://cmdchallenge.com/s/#/search_for_files_containing_string, the problem was:
Print all files in the current directory,
one per line (not the path, just the filename)
that contain the string "500".
When I ran:
ls -al
I got the following:
total 36
drwxr-xr-x. 2 501 dialout 4096 Feb 10 21:08 .
drwxr-xr-x. 39 501 dialout 4096 Apr 18 19:04 ..
-rw-r--r--. 1 501 dialout 204 Apr 29 17:44 README
lrwxrwxrwx. 1 501 dialout 23 Feb 10 20:59 access.log -> ../../common/access.log
lrwxrwxrwx. 1 501 dialout 25 Feb 10 21:08 access.log.1 -> ../../common/access.log.1
lrwxrwxrwx. 1 501 dialout 25 Feb 10 21:08 access.log.2 -> ../../common/access.log.2
I tried a few things, then looked at the user submitted solutions and one of them was:
ls *[^2]
I did some googling and the man page (and here), but I can't see what this is doing, or how it works.
Can anyone point me to a decent resource so I can read up on it, or tell me how it works?
Let me first quote PesaThes comment to what the command does:
The reference you are looking for is in the manual under: pattern matching. * matches any string, [^2] matches any character that is not 2. So the command lists all files that do not end in 2
Now why this is a solution to the problem is not so clear from your question alone. But if you look what the files contain you will notice that indeed, access.log.2 is the only one that does not contain the string 500 and also the only one whose name ends in 2.
For other sets of files the command ls *[^2] will most probably not output all the files without the string 500 in it, but in this case with those specific files it matches the right files. Another solution would have been for example
echo README; echo access.log; echo access.log.1
that's not an answer to your question, the right way of doing it is
$ grep -sl 500 * .*
-s skip errors (caused by directories); l only filenames; search in * all visible files and .* invisible files.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Basically, I want to get socket and pipe owners starting from a PID located in the /proc/PID/fd/ directory using the "stat" command:
lrwx------ 1 root root 64 dic 23 17:52 0 -> socket:[9790]
l-wx------ 1 root root 64 dic 23 17:52 1 -> /var/log/messages
l-wx------ 1 root root 64 dic 23 17:52 2 -> /var/log/secure
lr-x------ 1 root root 64 dic 23 17:52 3 -> /proc/kmsg
l-wx------ 1 root root 64 dic 23 17:52 4 -> /var/log/maillog
l-wx------ 1 root root 64 dic 23 17:52 5 -> /var/log/cron
How could I use "stat" to get each socket owner when I just have the socket name (socket:[9790]) instead of its symbolic reference (0,1,2...)?
Thanks for your answer!
For this lsof is much better.
You can use lsof -i -a -p $PID.
There is a similar question on the unix hub on the StackExchange.
https://unix.stackexchange.com/questions/235979/how-do-i-find-out-more-about-socket-files-in-proc-fd
I think that should solve your problem.
I do not think that you can do this with one simple stat instruction. Instead you could try to utilize find in order to search for symbolic links an then print them formatted. You can then, e.g., pipe the result to grep and cut to filter for the information you need:
find /proc/PID/fd/ -type l -printf '%u %l\n' 2>/dev/null|grep "socket:[9790]"|cut -d' ' -f1
You can use find's options (-mindepth, -maxdepth) in order to determine how deep it shall descend into subfolders for its search. If you want the owner's UID instead of the username then use %U instead of %u in -printf.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 4 years ago.
Improve this question
I found a file named '.|rst412slp10lad10_noTopo.png', and I really want to remove this. what should I do?
I tried to use ls -al to get the info of the file then I got this:
ls: cannot access '.|rst412slp10lad10_noTopo.png': No such file or directory
total 0
drwxrwxrwx 1 jinshengye jinshengye 4096 Jun 5 17:10 .
drwxrwxrwx 1 jinshengye jinshengye 4096 Jun 5 16:58 ..
-????????? ? ? ? ? ? .|rst412slp10lad10_noTopo.png
What should I do?
Find the inode number(s) with
ls -li
And remove it with
find . -inum 1234 -delete
OK you can try deleting with quotes
rm ".|rst412slp10lad10_noTopo.png"
but that probably won't work, you may need to set rights and /or reboot (or more)... Have a look at this:
https://serverfault.com/questions/65616/question-marks-showing-in-ls-of-directory-io-errors-too?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa
Since making a hash of a complete binary file would be far too heavy to compute in a reasonably fast time:
What are sufficient file information for hashing a file? The following lists what properties the resulting hashing should ideally have:
collision-free in respect to other files in the directory
fast
catch all file changes
As a rule of thumb, the less information we can use to create enough entropy, the better. Since the speed of retrieval for specific information may depend largely on the given environment (OS, file-IO of the language, IO of the used library, etc.), it should be disregarded here.
(This is my first attempt at a community wiki. My reason for making it one is that the information asked here is very generic but (hopefully) informative. I also would like this question to be marked as a community wiki, so it can be improved where fit. )
General Overview
Our goal here is to track as much differences between two file states while not using redundant data. Thus each informational source must be a disjointed subset of the information of the files state.
The following items represent sources of information about a file:
the name of the file
the directory-path relative to the specified document-root (aka absolute from document-root)
the files permissions
the files owner (user/group)
the last change time
the size of the file
the hostname of the machine the file resides on
the actual saved binary data
Per Item Considerations
Name of File
The name of the file is part of its absolute filesystem's path (the last bit) and as #La-comadreja said, it is unique in that no two files on a system can have the same absolute path. Using the File's name in combination with the rest of its absolute path (see directory-path for more information) is highly encouraged to avoid hash collisions with other files.
Directory-Path
While the files absolute path will be perfectly unique, it should be noted that in certain circumstances hashing the absolute path may be inappropriate. For instance, comparing the hashes of two files on different machines will most likely fail when both files do not have the identical absolute path on both machines. This becomes even more problematic on machines with different OS's and/or architectures. It is therefore encouraged to specify a document-root and resolve an absolute path from there.
Permissions
If you want to track changes to a files permissions, the tests below indicate that you would need to incoporate them into your hash directly as they do not change any other information about the file (most notably the timestamp). Note however that permissions are handled quite differently on different machines, so caution must be exercised here (for instance to use a canonical permission translation scheme).
Ownership
Ownership, just as permissions, is handled very differently across architectures and filesystems. A change of ownership does not change other information (as indicated by the tests below).
timestamp
The timestamp of a file is also something that is not unifiedly implemented across all (or at least the most common) systems. First of all, there are different timestamps on different filesystems we could be looking at: creation date, modified date, access date, etc. For our purpose the modified date is most suitable, as it is supported by most of the available filesystems [1] and holds the exact information we need: the last change to a file. However comparing files across different OS's may pose a problem, as Windows and Unix handle timestamps (in general) differently (see here [2] for a detailed article about the problem). Note that the modification date of a file changes whenever a file has been edited (disregarding edge cases), so timestamp indicates changes in file size (note that the opposite does not hold true, see file-size).
File size
The file size in bytes is an extremely good indication whether a file has been edited (except for permissions, ownership and name changes), as each edit would change the files content, thus changing its size. However this does not hold true if additions to a file are exactly as big as deletions. Thus the files timestamp may be a better indicator. Also, calculating a files binary size may be quite computation intensive.
Hostname
If one wants to compare files across multiple hosts and regard identical files on different hosts as different, then the hostname of the machine (or another suitable unique identifier for the host) should be included in the hash.
Binary Data
The binary data of the file has, of course, all necessary information to check if a file was changed. However, it is also too resource intensive to be of any practicability. It i highly discouraged to use this information.
Suggestions
The following sources should be used to compare files:
the name of the file
the directory path
the timestamp (see above for problems)
The following extra sources can be used to track more information:
permissions (see above)
ownership (see above)
hostname (when comparing across different machines)
The following sources of information should be disregarded:
file size
binary data
Tests
I did some tests on Debian checking whether changing one information would change another. Most interestingly rename, permission change, owner change did not affect a timestamp change or filesize change. (Note that these tests are currently only tested on Debian Linux. Other OS's will likely behave differently.)
$ ls -l
-rw-r--r-- 1 alex alex 30 Apr 26 11:04 bar
-rw-r--r-- 1 alex alex 0 Apr 26 11:03 baz
-rw-r--r-- 1 alex alex 14 Apr 26 11:04 foo
$ mv baz baz2
$ ls -l
-rw-r--r-- 1 alex alex 30 Apr 26 11:04 bar
-rw-r--r-- 1 alex alex 0 Apr 26 11:03 baz2
-rw-r--r-- 1 alex alex 14 Apr 26 11:04 foo
$ chmod 777 foo
$ ls -l
-rw-r--r-- 1 alex alex 30 Apr 26 11:04 bar
-rw-r--r-- 1 alex alex 0 Apr 26 11:03 baz2
-rwxrwxrwx 1 alex alex 14 Apr 26 11:04 foo
$ mv baz2 baz
$ echo "Another string" >> bar
$ ls -l
-rw-r--r-- 1 alex alex 45 Apr 26 11:17 bar
-rw-r--r-- 1 alex alex 0 Apr 26 11:03 baz
-rwxrwxrwx 1 alex alex 14 Apr 26 11:04 foo
$ sudo chown root baz
$ ls -l
-rw-r--r-- 1 alex alex 45 Apr 26 11:17 bar
-rw-r--r-- 1 root alex 0 Apr 26 11:03 baz
-rwxrwxrwx 1 alex alex 14 Apr 26 11:04 foo
Assuming all the files are on the same machine, directory path and file name should produce a unique combination because two files in the same directory cannot have the same name. Directory path, filename and timestamp of last change should capture each change.
If the files are on different machines, the machine name should be included in the directory path.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
Anywhere I ls -a folder contains files called "." and "..".
Anybody knows what is this stuff? Is this some system files? Is this some kind of a virus or something? I have hard time googling because of such file names.
Here is an example:
drwx------+ 12 mih staff 408 4 янв 16:49 .
drwxr-xr-x+ 91 mih staff 3094 20 мар 15:28 ..
-rw-r--r--# 1 mih staff 6148 4 янв 16:49 .DS_Store
-rw-r--r-- 1 mih staff 0 10 ноя 2011 .localized
-rw-r--r--# 1 mih staff 181 27 ноя 2011 Desktop.ini
-rw-r--r--# 1 mih staff 8198298 29 июл 2013 Dizzee Rascal - Bassline Junkie.mp3
Yes, those are system files.
A subdirectiry contains two directory entries that were used to navigate between folders in the early days of DOS.
The . entry is a directory reference to the same directory.
The .. entry is a directory reference to the parent directory.
Those are like regular subdirectories, but instead they point to directories that already exist.
Nowadays those wouldn't actually be needed, the system could interpret . and .. anyway, but in the early days they were needed for the system to find the way back to the parent directory.
"." is a representation of the current directory in Unix based systems. ".." Is for upper directory.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'm just getting started with GPG. I've created a key pair and now have several .gpg files:
drwx------ 2 jason jason 4096 Feb 11 21:10 ./
drwx------ 90 jason jason 45056 Feb 11 20:49 ../
-rw------- 1 jason jason 9398 Feb 11 20:49 gpg.conf
-rw-rw-r-- 1 jason jason 2316 Feb 11 21:10 mypk
-rw------- 1 jason jason 1633 Feb 11 20:52 pubring.gpg
-rw------- 1 jason jason 1633 Feb 11 20:52 pubring.gpg~
-rw------- 1 jason jason 600 Feb 11 20:52 random_seed
-rw------- 1 jason jason 1794 Feb 11 20:52 secring.gpg
-rw------- 1 jason jason 1280 Feb 11 20:52 trustdb.gpg
Am I correct to understand that secring.gpg is my private key? This file is protected by my passphrase, right? Is it ok to just keep this file on my machine? Should I move it somewhere more secure (say a thumb drive)?
Am I correct to understand that secring.gpg is my private key?
From man gpg:
~/.gnupg/secring.gpg
The secret keyring. You should backup this file.
This file is protected by my passphrase, right?
If you set one, yes. Actually not the file itself is protected, but each contained key can be (you can have multiple private keys in your secret keyring).
Is it ok to just keep this file on my machine? Should I move it somewhere more secure (say a thumb drive)?
This depends on your needs and trust in your machine.
Do you have special security needs, share your machine or expect it to be hacked/stolen/...? Better put it on an external device and then reference it using --secret-keyring /path/to/secring.gpg whenever using gpg or put it into your gpg.conf: secret-keyring /path/to/secring.gpg.
Do you trust the integrity of your computer, possibly even encrypted your files on it? Will you have to use your secret key a lot? Better keep the file on your hard drive as this saves hassles with using gpg.
For putting your key on a separate device, think of using an OpenPGP card. Using one, your secret key will never leave that card (for signing and decrypting) but for backup purpose. Definitely increases nerd factor, too. ;)