> /etc/devfs.conf:perm xpt0 0666 #permissions are set properly at
> boot
>
> ... which is still largely un-intelligible to me, at the moment. and which
> co-incides, oddly enough, with the moment at which i have to leave for
> work! dang! so i'll have to take another google around, later tonight...
perm means permissions are being set, xpt0 is the device ('ls /dev') 0666 are
the permissions. 4=read-only, 5=readable-and-executable, 6=readable-writable,
7=readable-writable-executable. See 'man chmod'. The first (the zero) is for
special settings, they don't matter now, the first 6 means that 6 is the
permission for the owner of the file, the second for the group (in which the
owner normally resides) and the third for "others", outsiders. "others" might
be pseudo-users that the system uses to run certain services as (they can't
log into a shell, it's a safety measure) but if one of those got broken into
you wouldn't want them to be able to access your devices so easily. So turn
the last 6 into a 0.
If you can't use your CD burner or other device that needs write access to xpt
after that, do the sane thing and add your normal user account to the group
to which your device or the ones working with it belong. For scsi-emulated
cd's (cd/dvd writing) through atapicam that would be the operator group.
Edit /etc/group to have operator:*:5:root,you instead of operator:*:5:root.
Much safer and more convenient to do it this way: Have preferenced groups and
add preferenced users to that group, instead of making every device readable
and writeable to every nobody. Same strategy should be followed with dvd's,
removable devices, tv cards, etc, anything that might require writing to the
device by an ordinary but privileged user (you).
Devfs is a lot better than the static devices we had before (4.X and before)
where all possible devices (when supported in the kernel or with modules) had
to be hardcoded whether they were really present or not.
> > grep's command line can be made to look less scary like:
> > grep <options> <search string> <filename>
>
> yes. that helps. i did sort of think of it in those terms.
>
> > or grep -ri "something" /etc/* which searches recursively, and ignores
> > What you did when you didnt tell grep what file to use for input was
FWIW, I have a great preference for using grep after a pipe, I get confused by
its options also so I tend to avoid them (except -v), e.g
cat file | awk { something } | sed s/something/something_else/g | grep keyword
That kind of thing. But it's a matter of taste and familiarality with grep I
guess.
> > I'm pretty sure that searching google a little bit can help you with
> > UNIX basics.
>
> there is a lot of stuff out there, i agree. making sense of it's another
> story
> though.
Look into tools and learn the few that for some reason appeal to you. Learn
some inside out and others briefly. There's many ways to Rome you know...
just get aquainted with enough tools so that you have your easy (well known)
preferences and know enough about some others to be able to rudimentally use
them. IMHO that should be enough to get by.
For general tricks and tips search for general unix/shell/sh/bash/csh how-to's
and console tips. The book Unix Power Tools is a great resource also, though
today I'd recommend to just google with the right terms.
HTH,
Dan
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
