Programming

Stupid question, but is there an ANSI C stdlib function that will do this for me? I want to pass the function a path and determine if the current process can read/write/execute on the path. I suppose I can whip something up using fstat and then determining the current process's user/group IDs and checking against the file's mode...but I don't want to reinvent the wheel if something already exists.

Thanks!

-- DreamWarrior

P.S. I am sure this is a n00b question, and I'm in fact even surprised in all my years I've never actually done anything like this. I typically just try to open the file in read/write mode and if it fails assume I can't...but for this particular instance, that's not going to work nicely.

man 2 access, but often I do this sort of thing in the wrapper ksh "if [ ! -w $file ] ; then . . . .".
man 2 stat tells you all the ls -ld stuff for a file and more, but then you have to decode permissions.

FWIW: use access(), calling shell from C obviates the use of C in the first place, especially when there is already an systen call for the exact problem you have. If you think about it, the "shell shortcut" must be using the system call.

test -<one letter goes here> or the [ -<one letter goes here> [filename] ] construct in shell does EXACTLY what stat & access can do in C. There they must call... you guessed it.

I find it is less code and especially less testing to do the once-daily or once-hourly housekeeping tasks in shell, especially when shell has many handy tools for that, and do just the need-for-speed bits in very simple C. I am not much into system calls, popen() occasionally so as not to have to rewrite thing and so as to get multiprocessing. I did find this was a nice system call, if you want a sort, like in COBOL (-:

Code:

system 'mknod /tmp/xxx p ; sort . . . -o /tmp/xxx /tmp/xxx &'
Open, Write data to, close /tmp/xxx
open, read result from, close /tmp/xxx
unlink() /tmp/xxx

So, was access() what you needed?

All this is in the 'Art of UNIX Programming':
http://www.catb.org/esr/writings/tao...hing-guide.pdf
This was a small book for years, now it is a pdf online. Still available as a book, too.


A generally accepted guideline for language choice UNIX programming:

1. do it all in shell first.
2. if #1 won't work, don't use shell, resort to perl, python, ruby
3. if #2 won't work or speed is the primary requirement, don't use perl etc., use all C/C++

Going back up from C to shell kinda defeats having gone down to a compiled language to start with. What you are doing is calling another gigantic C program.

Note --

We have some extraordinary shell programmers here. See some of CFA Johnson's posts, or google his book. You can do a lot more than you realize just in shell. So going to #2 & #3 is not as common as you might think.

Also some shells like bash are easily extensible. Need a command - create your own builtin.
Using and Writing Bash Dynamically Loadable Built-In Commands by Chris F.A. Johnson

Yes, thanks. I'm amazed I've never needed this call before, but it does exactly what I need and I'm glad I don't have to resort to doing myself with stat.

Thanks y'all...

I write a lot of my C programs as relatively simple shell assists, so I can very easily test them and then use them with confidence. I like to write streaming tools (pipe fittings), where the input is usually not the command line, but lines on stdin. Before getting hung up on single app specific code that is hard to test, consider the simple shell assist C program.

For instance, mystat takes in paths from stdin as lines and spits them back out prefixed with one stat structure element and a tab, sort of like 'ls' but with no line length limit, headers, summaries or sorting. It's great for finding the latest in a list too big for ls -ltr. The code is so simple, you should be able to imagine it just from this. Originally, it just did mtime. I made up one letter mnemonic codes for every stat element, and default to mtime.

Another toy, xdemux, starts $1 instances of popen() $2 to write FILE*'s and sends incoming lines to them, in simple rotation. This does up to 32 parallel fgreps (great for 16 CPUs) looking for a string in a big file list:

Code:

find / -type f | xargs 32 'xargs -n999 fgrep -l aardvark'

I am sure some of my C toys could be done in *sh, but in C they can be both very heavy-duty in terms of speed and very robust, with no metacharacter worries. When possible, they have no char[] to be too short (or I go really big), using one character at a time I/O and state variables. If you do not write your commands for a big future, I guess you do not believe you have a big future?