trying to run arbitrary commands and parse their output - c

here is part of code
scanf("%[^\n]%*c",command);
int pid;
pid=fork();
if (pid == 0) {
// Child process
char *argv[]={command ,NULL};
execvp(argv[0], argv);
exit (0);
}
When I give as input ls I want as output
1 copy of mysh1.c mysh1.c mysh3.c mysh.c New Folder
a.out helpmanual.desktop mysh2.c mysh4.c New File
and when i give ls -l /tmp
i'm waiting
total 12
-rw------- 1 antre antre 0 Nov 4 17:31 config-err-KT9sEZ
drwx------ 2 antre antre 4096 Nov 4 19:21 mozilla_antre0
drwx------ 2 antre antre 4096 Jan 1 1970 orbit-antre
drwx------ 2 antre antre 4096 Nov 4 17:31 ssh-HaOFtKdeIQnQ `
but i take:
1 copy of mysh1.c mysh1.c mysh3.c mysh.c New Folder
a.out helpmanual.desktop mysh2.c mysh4.c New File

It seems that you're trying to parse the output of ls -l in a C program for some reason.
That's unlikely to be the “right” thing to do. The usual mechanism is to use opendir and readdir to read the directory file, directly.
If you have some truly strange situation in which you cannot opendir (the only case that comes to mind is if you're running ls on a remote system, eg, over ssh), there is a mode in GNU ls specifically for producing an output record format that can be parsed by another program.
From the GNU coreutils info:
10.1.2 What information is listed
‘-D’
‘--dired’
With the long listing (‘-l’) format, print an additional line after
the main output:
//DIRED// BEG1 END1 BEG2 END2 ...
The BEGN and ENDN are unsigned integers that record the byte
position of the beginning and end of each file name in the output.
This makes it easy for Emacs to find the names, even when they
contain unusual characters such as space or newline, without fancy
searching.
If directories are being listed recursively (‘-R’), output a
similar line with offsets for each subdirectory name:
//SUBDIRED// BEG1 END1 ...
Finally, output a line of the form:
//DIRED-OPTIONS// --quoting-style=WORD
where WORD is the quoting style (*note Formatting the file
names::).
Here is an actual example:
$ mkdir -p a/sub/deeper a/sub2
$ touch a/f1 a/f2
$ touch a/sub/deeper/file
$ ls -gloRF --dired a
a:
total 8
-rw-r--r-- 1 0 Jun 10 12:27 f1
-rw-r--r-- 1 0 Jun 10 12:27 f2
drwxr-xr-x 3 4096 Jun 10 12:27 sub/
drwxr-xr-x 2 4096 Jun 10 12:27 sub2/
a/sub:
total 4
drwxr-xr-x 2 4096 Jun 10 12:27 deeper/
a/sub/deeper:
total 0
-rw-r--r-- 1 0 Jun 10 12:27 file
a/sub2:
total 0
//DIRED// 48 50 84 86 120 123 158 162 217 223 282 286
//SUBDIRED// 2 3 167 172 228 240 290 296
//DIRED-OPTIONS// --quoting-style=literal
Note that the pairs of offsets on the ‘//DIRED//’ line above
delimit these names: ‘f1’, ‘f2’, ‘sub’, ‘sub2’, ‘deeper’, ‘file’.
The offsets on the ‘//SUBDIRED//’ line delimit the following
directory names: ‘a’, ‘a/sub’, ‘a/sub/deeper’, ‘a/sub2’.
Here is an example of how to extract the fifth entry name,
‘deeper’, corresponding to the pair of offsets, 222 and 228:
$ ls -gloRF --dired a > out
$ dd bs=1 skip=222 count=6 < out 2>/dev/null; echo
deeper
Note that although the listing above includes a trailing slash for
the ‘deeper’ entry, the offsets select the name without the
trailing slash. However, if you invoke ‘ls’ with ‘--dired’ along
with an option like ‘--escape’ (aka ‘-b’) and operate on a file
whose name contains special characters, notice that the backslash
is included:
$ touch 'a b'
$ ls -blog --dired 'a b'
-rw-r--r-- 1 0 Jun 10 12:28 a\ b
//DIRED// 30 34
//DIRED-OPTIONS// --quoting-style=escape
If you use a quoting style that adds quote marks (e.g.,
‘--quoting-style=c’), then the offsets include the quote marks. So
beware that the user may select the quoting style via the
environment variable ‘QUOTING_STYLE’. Hence, applications using
‘--dired’ should either specify an explicit
‘--quoting-style=literal’ option (aka ‘-N’ or ‘--literal’) on the
command line, or else be prepared to parse the escaped names.

i just only needed to use strtok

Related

Brace expansion in zsh - how to concatenate two lists for file selection?

In zsh, one can create an expression of {nx..ny}, for example to select files x to y inside a folder.
For example, {1..50} selects items, files, etc. from 1 to 50.
How can I concatenate two two brace expansions into one?
Example: I would like to select {1..50} and {60..100} for one and the same output.
You can nest brace expansions, so this will work:
> print {{1..50},{60..100}}
1 2 3 (lots of numbers) 49 50 60 61 (more numbers) 99 100
Brace expansions support lists as well as sequences, and can be included in strings:
> print -l file{A,B,WORD,{R..T}}.txt
fileA.txt
fileB.txt
fileWORD.txt
fileR.txt
fileS.txt
fileT.txt
Note that brace expansions are not glob patterns. The {n..m} expansion will include every value between the start and end values, regardless of whether a file exists by that name. For finding files in folders, the <-> glob expression will usually work better:
> touch 2 3 55 89
> ls -l <1-50> <60-100>
-rw-r--r-- 1 me grp 0 Feb 18 06:52 2
-rw-r--r-- 1 me grp 0 Feb 18 06:52 3
-rw-r--r-- 1 me grp 0 Feb 18 06:52 89

tr not impacting file command output

If I run:
$ ls -l /tmp
total 16
drwxr-xr-x 2 noaccess noaccess 177 Nov 18 09:53 hsperfdata_noaccess
drwxr-xr-x 2 root root 117 Nov 18 09:53 hsperfdata_root
I get the expected result running:
]$ ls -l /tmp | tr -s '[:space:]'
total 16
drwxr-xr-x 2 noaccess noaccess 177 Nov 18 09:53 hsperfdata_noaccess
drwxr-xr-x 2 root root 117 Nov 18 09:53 hsperfdata_root
Yet tr will not impact file output:
$ file /tmp/dummy
/tmp/dummy: empty file
$ file /tmp/dummy | tr -s '[:space:]'
/tmp/dummy: empty file
(the same if I use [:blank:])
I was expecting:
$ file /tmp/dummy | tr -s '[:space:]'
/tmp/dummy: empty file
Am I misusing file? tr? Must I awk? I'm using bash 3.2.51 on SunOS 5.10 and would like to tell XML and gz files apart.
The Solaris 5.10 version of file is producing output that uses tabs instead of spaces:
$ touch /tmp/dummy
$ file /tmp/dummy | cat -vet
/tmp/dummy:^Iempty file$
$
In this case, tr -s squashes a single tab character down to a single tab character...

The influence of file mode when file is read and written by a same user in different processes

This is my code
fd=open("a",O_RDWR | O_CREAT);
printf("%d\n", fd);
if(fd < 0)
{
perror("error");
exit(1);
}
lseek(fd, 0, SEEK_SET);
read(fd, buf, 10);
write(STDOUT_FILENO, buf, 10);
getchar();//1
lseek(fd, 0, SEEK_SET);
write(fd, "xxxxxxxxxx", 10);
getchar();//2
lseek(fd, 0, SEEK_SET);
read(fd, buf, 10);
write(STDOUT_FILENO, buf, 10);
getchar();//3
next is something about file a
//file a, mode 600
//aaaaaaaaaaa
when at step 2, the text of file a will be changed into "xxxxx...".
then I use vim to change the text into "bbbbbbb..." in another terminal.
the output at step 3 is "xxxxx..."
however, when file a is
//file a, mode 606 or 660
//aaaaaaaaaaaa
do same thing as above
the output is "bbbbbbb...."
my system is os x 10.9
I can reproduce the problem, to my considerable surprise (Mac OS X 10.9.4).
However, as I hinted might be a possibility in my comment, the problem seems to be that vim is changing the inode number of the file when the file has 600 permission:
$ for mode in 600 606 660 666
> do
> echo "Mode: $mode"
> echo "abcdefghijklmnopqrst" > a
> chmod $mode a
> ls -li a
> vim a
> cat a
> ls -li a
> done
Mode: 600
25542402 -rw------- 1 jleffler staff 21 Sep 2 07:58 a
xxxxxxxxxxklmnopqrst
25542484 -rw------- 1 jleffler staff 21 Sep 2 07:58 a
Mode: 606
25542484 -rw----rw- 1 jleffler staff 21 Sep 2 07:58 a
xxxxxxxxxxklmnopqrst
25542484 -rw----rw- 1 jleffler staff 21 Sep 2 07:58 a
Mode: 660
25542484 -rw-rw---- 1 jleffler staff 21 Sep 2 07:58 a
xxxxxxxxxxklmnopqrst
25542484 -rw-rw---- 1 jleffler staff 21 Sep 2 07:58 a
Mode: 666
25542484 -rw-rw-rw- 1 jleffler staff 21 Sep 2 07:58 a
xxxxxxxxxxklmnopqrst
25542484 -rw-rw-rw- 1 jleffler staff 21 Sep 2 07:58 a
$
In each case, I ran the command 10rx and :x in vim.
I'm not clear why vim needs to change the inode when the file is 600 permission, but it smacks of a bug from where I'm sitting. It is behaviour I would not have expected at all (except that it explained what you saw).
Because the 'file descriptor' program (the outline code in the question) keeps the same file open, the inode number of the file it is working with does not change, but because vim rewrites the file with a new inode number (meaning: it creates a new file with a new name and inode number containing the modified contents, then removes the old version of a and replaces it with the new file), the edit made by vim (when the file has 600 permission) is not seen in the file that the program has open. At the end of the 'file descriptor' program when the permissions are 600, the file that it had open has no name and its contents are deleted by the system; the file that vim created has taken the place of the original file.

Why do dots ("." and "..") appear when I print files from directory?

I'm printing files from two directories using C language. Here is my code:
char *list1[30], *list2[30];
int i=0, x=0;
struct dirent *ent, *ent1;
/* print all the files and directories within directory */
while ((ent = readdir (dirSource)) != NULL) {
list1[i] = ent->d_name;
i++;
}
i=0;
while((ent1 = readdir (dirDest)) != NULL) {
list2[i] = ent1->d_name;
i++;
}
while(x != i){
printf("Daemon - %s\n", list1[x]);
printf("Daemon1 - %s\n", list2[x]);
x++;
}
I can print all the files, but everytime I print the files in a directory, the end result is this:
Daemon - .
Daemon1 - .
Daemon - ..
Daemon1 - ..
Daemon - fich5
Daemon1 - fich4
Daemon - fich3
Daemon1 - fich3
I don't understand why there are dots in the beginning.
Obs.: I don't if it matters, but I'm using Ubuntu 14.04 on a pen, meaning every time I use Ubuntu, I use the trial instead of using dual boot on my pc.
. and .. are two special files which are in every directory in Linux and other Unix-like systems. . represents the current directory and .. represents the parent directory.
Every directory in Unix has the entry . (meaning current directory) and .. (the parent directory).
Give that they start with "." they are hidden files; ls normally do not show them unless you use "-a" option.
See:
[:~/tmp/lilla/uff] % ls -l
total 0
-rw-rw-r-- 1 romano romano 0 May 17 18:48 a
-rw-rw-r-- 1 romano romano 0 May 17 18:48 b
[:~/tmp/lilla/uff] % ls -la
total 8
drwxrwxr-x 2 romano romano 4096 May 17 18:48 .
drwxrwxr-x 3 romano romano 4096 May 17 18:47 ..
-rw-rw-r-- 1 romano romano 0 May 17 18:48 a
-rw-rw-r-- 1 romano romano 0 May 17 18:48 b

Unix `find` command that returns path and whether or not it's a file/directory?

When you do ls -la it returns each path along with info of whether or not it's a file/directory:
$ ls -la
drwxr-xr-x 11 viatropos staff 374 Jan 21 21:24 .
drwxr-xr-x 41 viatropos staff 1394 Feb 2 00:48 ..
-rw-r--r-- 1 viatropos staff 43 Jan 21 21:23 .gitignore
-rw-r--r-- 1 viatropos staff 43 Jan 21 21:23 .npmignore
-rw-r--r-- 1 viatropos staff 647 Jan 21 21:23 README.md
-rw-r--r-- 1 viatropos staff 3069 Feb 5 20:17 index.js
drwxr-xr-x 8 viatropos staff 272 Feb 5 20:06 node_modules
-rw-r--r-- 1 viatropos staff 291 Jan 21 21:24 package.json
drwxr-xr-x 4 viatropos staff 136 Jan 21 21:23 test
Is there a way to do this using the find command (and glob * functionality)? So, finding all paths within node_modules and having it return the path and whether or not it's a file directory? Something like:
$ find node_modules -name 'lib/*'
d node_modules/express/lib/
f node_modules/express/lib/index.js
...
How about find ... -printf '%y %p\n'? (This is probably a GNU find extension, though.)
Try this script, I called it "findfl". The "mtime" clause finds files changed in the last 3 days.
Directories will have "/" appended.
#!/bin/sh
# find files produced recently, matching input pattern
[ $1 ] || { echo "Usage: findfl <file-name-pattern>" ; exit ; }
TOPDIR=/home/usr/fred #the directory you want to search
echo "Searching $TOPDIR"
find . -mtime -3 -name *$1* 2>/dev/null | xargs -n 99 ls -lptr | sed "s! ./! $TOPDIR/!g"

Resources