In using the uname command the following three options gives me the same output:
ubuntu@ip-172:~/asm/asm$ uname -p
# x86_64
ubuntu@ip-172:~/asm/asm$ uname -i
# x86_64
ubuntu@ip-172:~/asm/asm$ uname -m
x86_64
Are the -m, -i, and -p options essentially the same thing, are what is the difference between them? From the man:
-m, --machine
-p, --processor print the processor type (non-portable)
-i, --hardware-platform print the hardware platform (non-portable)
In the manual for Gnu "ls," I see this:
--author
with -l, print the author of each file
Does anybody know what the “author” of a file means in this context?
This is (maybe?) not the file's owner, which is listed already with -l … or is it? Perhaps this refers to a different type of filesystem than mine (ext4), that has a distinction between "author" and "owner?"
On my machine, it seems to uniformly duplicate the "owner" column, but I'm definitely curious about this one.
Perhaps this is just the worst combination of "noise" keywords ever, but I can't find anything relevant online (neither /usr/share/{man,info} nor StackExchange nor Google), but “author” is practically a noiseword :-(
I suppose, if all else fails, I can dig through the coreutils sources…
date --set="2011-12-07 01:20:15.962" && date --rfc-3339=ns
I can get the date with milliseconds like so:
date +"%S.%N"
date --rfc-3339=ns
According to man date I would expect to be able to set it like so:
date --set=%s.%N +`date +"%S.%N"`
date --set="%s.%N" "+1323217126.085882000"
According to my googling I would expect to be able to set the date like so (the inverse of the above):
date +%s.%N -s `date +"%S.%N"`
date +"%s.%N" -s "1323217126.085882000"
Neither work. Can someone clue me in on the issue?
P.S. No, I don't need nanosecond resolution. Yes, I know bash execution takes milliseconds. What I really need is sub-second resolution, 10ths of a second would be good enough.
I have a directory which can be read and written by a couple of unix groups. This is achieved by using ACLs. Let's assume I did it like this:
mkdir /tmp/test
setfacl -d -m g:group1:rwx /tmp/test
Works great, the whole group (And other groups I add like this) can read/write to this directory. BUT there is one exception: When someone creates a subfolder by using mkdir -p then this directory is created with the unix permissions 0755 because the default umask is 022. This results in the problem that other users of the group can no longer write to this subfolder because the ACL now looks like this:
group:group1:rwx #effective:r-x
For some reason this doesn't happen when using "mkdir" (Without -p argument). One solution is setting the umask to 002 but this is really a bad thing because this also affects files and directories created outside of the ACL-controlled directories and these files should not be group writable per default.
So I wonder if there is another possibility to solve this problem. It would be perfect to be able to completely disable/ignore the old unix-style permission stuff for a ACL-controlled directory. Or disable this "effective ACL" stuff. Is that possible? Or is there another way to solve the problem with unwritable directories caused by programs like "mkdir -p"? In the end I want a directory which is completely (and recursively) readable and writable according to the ACLs I have configured and this should never change (Only by modifying the ACLs itself).
Note: to reproduce the problem:
$ mkdir /tmp/test
$ setfacl -d -m g:group1:rwx /tmp/test
$ umask 0022
$ mkdir /tmp/test/aa
$ mkdir -p /tmp/test/bb
$ ls -log /tmp/test
drwxrwxr-x+ 2 4096 Mar 9 23:38 aa
drwxr-xr-x+ 2 4096 Mar 9 23:38 bb
$ getfacl /tmp/test/bb | grep ^group:group1
group:group1:rwx #effective:r-x
I am a Windows user who wants programs like grep and sed along with other utilities like ls, cut etc in my command prompt. I came across 2 packages which would accomplish this
I would like to know what is the difference between the two both feature wise and more importantly performance wise before I choose between them. From what I have seen Coreutils is a super set of UnxUtils. Is this correct ?