This one is probably pretty simple -- now that the change program exists,
I can't type !change list to alter my conference list.  Problem is, when
I try to !es .cflist, I end up starting a new file.  Not what I had in mind.
So, now what?  Where is my conference list?  How do I change it?

Thanks for the help!

25 responses total.

Well, "!change list" will run the change program, which as far as I
know can't edit files.  So that's completely wrong.

If it's telling you the file doesn't exist, then you're probably
in the wrong working directory.  Try running this instead:

        !es /usr/home/mta/.cfdir/.cflist

(Your account was moves to a different partition than the rest
of us, this may be part of the problem.)

This response has been erased.

This response has been erased.

Aha!  It works!  Thanks!

I created a .cflist and put everything with .cf* and .*.cf in it. Now,
an  n  at an Ok: prompt no longer goes to the next .cf in .cflist.
What else do I need to do?

ARGGGH! I meant, I created a .cfdir   (where is that script that enters
what I'm thinking rather than what I type?).

This response has been erased.

No, the problem is stated in #5 (substitute .cfdir for the first .cflist).
I've had a .cflist, and it worked fine, until I moved it and all other
.cf files into .cfdir.

At a guess, the problem is the permissions on your .cfdir.  This is just a
guess!  But you might try (at a shell prompt) chmod +r .cfdir and see if
that fixes it.  The x permission you've given everyone else should let the
.cflist be opened, but doesn't let Picospan check which files are in the
dir, & I'm guessing that it does something like that.

Bingo! Permitting .cfdir read all did not itself solve the problem, but it
prompted me to permit .cflist 644, rather than 600, which it had been, and
that did the trick. Apparently .cflist being 600 is OK in a home
directory, but not in a.cfdir subdirectory. Thanks, Dave. 

This response has been erased.

I have discovered the source of my problem. When I copied all the cf files
in my directory into the subdirectory .cfdir, all the read perms to others
were removed. I did not know that would happen.  What is the general rule
for this, and can the file be copied with original perms? (You say, RTFM?)

Aha.  When you *copy* files, by default your current umask is used.  So
the first piece of advice is: if you're moving files, don't use cp, use mv.
But if copying is what you want, then    cp -p   will preserve the file's
timestamp & permissions.  You may also want to check out the -i option
(on both cp and mv), which prompts you before overwriting.  And, yes, RTFM.

Thanks, Dave. I couldn't think of the move command at the moment B^\.

I want to bring more order into my .cflist, so it occurred to me to just
use the "help conferences" list, and "comment out" those I don't want to
goto.  Can one "comment out" lines in .cflist?

This response has been erased.

I was going to suggest that either # or . or , might *avoid* those errors,
but I didn't (& don't) intend to take the time to test it out.

FWIW, I shuffle those conferences I want to ignore until I have time
to the bottom of my .cflist.  That way, when I hit the first of them, I
just exit.

I just tried:  :.#;! and ,  The last (,) was ignored by Picospan
and the rest caused a "cannot access" error for the conference.  If
the magic comment character exists for .cflist, it must be something
else.

I also tried: ~@^" and >. Nada. 

This response has been erased.

Sorry - PicoSpan doesn't support comments in .cflist files.

It also seems to be very picky indeed.  I just fixed the longstanding problem
of my .cflist not being read by one of two final changes: I deleted the copy
of my .cflist not in my .cfdir, and changed my group permission to +x on my
.cfdir (somehow, I suspect it was the former twiddle that caused the fix, but 
I'm not about to test it on the "It Aint Broke..." principle), while all other
perms remained the same.
        I do marvel that it is considered necessary to make picospan ("bbs")
both sgid (which is normal) and suid (which is most emphatically NOT).  This 
both creates the problem that Picospan cannot read any files which it's user 
wishes to keep private from the rest of the world, and on the security end of
compromise of /usr/local/bin/bbs gives full control to all files owned by cfadm
A far more sensible approach would be to make /usr/local/bin/bbs sgid, and have
an external program (which was only readable/executable by things in the cfadmg
group) which could be used by Picospan to create directories/files with the 
proper ownership (since all else can be handeled seamlesly with sgid).  This 
would mean that Picospan could read/write files owned by the user, and would be
the user at all times when not creating an item (and only for brief moments
then).

This response has been erased.

I'll take your word that he did, but that doesn't mean that his reasons
resulted in the best solution.
 :)

Yes, PicoSpan is SUID for a reason.

Response not possible - You must register and login before posting.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss