Loading ...
Sorry, an error occurred while loading the content.
 

Re: [LINUX_Newbies] Re: crontab changes won't take

Expand Messages
  • Chad Martin
    ... No, I haven t checked that. How does one figure that out other than the fact that it s a little sore when you sit? ;) Chad Martin
    Message 1 of 30 , Jun 7, 2003
      Mike Peters wrote:
      > I haven't been particuarly following this thread and my internet
      > connection is acting too flakey at the mo' to check the archives so I'm
      > sorry if I'm repeating something someone's already said but..Have you
      > checked the integrety of your cron binary? ie are you sure you haven't
      > been backdoored?

      No, I haven't checked that. How does one figure that out other than the
      fact that it's a little sore when you sit? ;)

      Chad Martin
    • Mike Peters
      On Sat, 07 Jun 2003 11:47:16 -0500 ... Check the md5sum of crond (provided you know what the value should be for your version). A quick check though is to
      Message 2 of 30 , Jun 7, 2003
        On Sat, 07 Jun 2003 11:47:16 -0500
        Chad Martin <chad@...> wrote:

        > Mike Peters wrote:
        > > I haven't been particuarly following this thread and my internet
        > > connection is acting too flakey at the mo' to check the archives so
        > > I'm sorry if I'm repeating something someone's already said
        > > but..Have you checked the integrety of your cron binary? ie are you
        > > sure you haven't been backdoored?
        >
        > No, I haven't checked that. How does one figure that out other than
        > the fact that it's a little sore when you sit? ;)
        >
        > Chad Martin

        Check the md5sum of crond (provided you know what the value should be
        for your version). A quick check though is to check the size and/or date
        of the binary against a known good copy (from your distro cd for
        example) using 'du' or 'ls -l'. However, bear in mind that if you have
        been compromised (ooh-er missus!!), you mightn't be able to trust the
        output from ls or du either, so check by booting from a clean bootdisk
        to be sure.
        --
        Mike
        Web Site: http://www.ice2o.com
        JabberID: mpeters@...
        Registered Linux User #247123

        It was all very well going about pure logic and how the universe was
        ruled by logic and the harmony of numbers, but the plain fact was that
        the disc was manifestly traversing space on the back of a giant turtle
        and the gods had a habit of going round to atheists' houses and smashing
        their windows.
        (Colour of Magic)
      • Mike Peters
        On Sat, 7 Jun 2003 22:18:20 +0300 ... Which wont work of course because the one on the cd will be a tgz or an rpm, Doh! But you get the idea. -- Mike Web Site:
        Message 3 of 30 , Jun 7, 2003
          On Sat, 7 Jun 2003 22:18:20 +0300
          Mike Peters <mike@...> wrote:

          > (from your distro cd for example)

          Which wont work of course because the one on the cd will be a tgz or an
          rpm, Doh! But you get the idea.

          --
          Mike
          Web Site: http://www.ice2o.com
          JabberID: mpeters@...
          Registered Linux User #247123

          ...And sometimes there's a short cut. A door or a gate. Some standing
          stones. A tree cleft by lightning, a filing cabinet. Maybe just a spot
          onsome moorland somewhere... A place where THERE is very nearly HERE...
          If some people knew where such a spot was, if they had experience of
          what happens when here and there become entangled, then they might - if
          they knew how - mark such a spot with certain stones. In the hope that
          enough daft buggers would take it as awarning and keep away.
          (Lords and Ladies)
        • Cameron Simpson
          ... The rpm command has some --verify options in the query section for doing exactly this. Provided your RPM db hasn t been hacked. -- Cameron Simpson
          Message 4 of 30 , Jun 7, 2003
            On 22:25 07 Jun 2003, Mike Peters <mike@...> wrote:
            | On Sat, 7 Jun 2003 22:18:20 +0300
            | Mike Peters <mike@...> wrote:
            | > (from your distro cd for example)
            |
            | Which wont work of course because the one on the cd will be a tgz or an
            | rpm, Doh! But you get the idea.

            The rpm command has some --verify options in the query section for doing
            exactly this. Provided your RPM db hasn't been hacked.
            --
            Cameron Simpson <cs@...> DoD#743
            http://www.cskk.ezoshosting.com/cs/

            Number of people in the workforce per Social Security beneficiary...
            in 1949: 13
            in 1990: 3.4
            in 2030: 1.9
          • Cameron Simpson
            ... So the change got applied. ... Hmm. Have you tried adding a chnage that _isn t_ a comment (i.e. the timing or the command)? Just in case cron is smart .
            Message 5 of 30 , Jun 7, 2003
              On 00:21 07 Jun 2003, Chad Martin <chad@...> wrote:
              | > Now stat the file again as before. Has it changed? Cat it - goes your
              | > change appear?
              | [root@ns /root]# ls -ld /tmp/*
              | -rw------- 1 root root 725 Jun 6 23:33 /tmp/crontab.13872
              | catting it shows the comment line I added.

              So the change got applied.

              | > Now type ":q" to your "crontab -e". Does cron still report "no changes
              | > made to crontab"?
              | Yup. And a subsequent crontab -e shows that the changes were not, in
              | fact, saved.
              | > Hopefully somewhere in this sequence we will see something not happening
              | > as expected.
              | No luck, I'm afraid.

              Hmm. Have you tried adding a chnage that _isn't_ a comment (i.e. the
              timing or the command)? Just in case cron is "smart".

              The next step is an strace, but please try a semantic change first.
              --
              Cameron Simpson <cs@...> DoD#743
              http://www.cskk.ezoshosting.com/cs/

              Only a moron would believe any of this crap.
              maverick@... in alt.food.mcdonalds
            • Chad Martin
              ... To the temp file, yes. To the spool file, no. ... Yup. That was what originally caught my attention. I tried changing the email address of a mail
              Message 6 of 30 , Jun 7, 2003
                Cameron Simpson wrote:
                > On 00:21 07 Jun 2003, Chad Martin <chad@...> wrote:
                > | > Now stat the file again as before. Has it changed? Cat it - goes your
                > | > change appear?
                > | [root@ns /root]# ls -ld /tmp/*
                > | -rw------- 1 root root 725 Jun 6 23:33 /tmp/crontab.13872
                > | catting it shows the comment line I added.
                >
                > So the change got applied.

                To the temp file, yes. To the spool file, no.

                > | > Now type ":q" to your "crontab -e". Does cron still report "no changes
                > | > made to crontab"?
                > | Yup. And a subsequent crontab -e shows that the changes were not, in
                > | fact, saved.
                > | > Hopefully somewhere in this sequence we will see something not happening
                > | > as expected.
                > | No luck, I'm afraid.
                >
                > Hmm. Have you tried adding a chnage that _isn't_ a comment (i.e. the
                > timing or the command)? Just in case cron is "smart".

                Yup. That was what originally caught my attention. I tried changing
                the email address of a mail command in my crontab, and the change was
                never saved.

                > The next step is an strace, but please try a semantic change first.

                I'm all ears.

                Chad
              • Chad Martin
                ... Well, now that you mention it, up2date complains of a DB problem whenever it tries to install a new package, but it hasn t seemed to have affected the
                Message 7 of 30 , Jun 7, 2003
                  Cameron Simpson wrote:
                  > On 22:25 07 Jun 2003, Mike Peters <mike@...> wrote:
                  > | On Sat, 7 Jun 2003 22:18:20 +0300
                  > | Mike Peters <mike@...> wrote:
                  > | > (from your distro cd for example)
                  > |
                  > | Which wont work of course because the one on the cd will be a tgz or an
                  > | rpm, Doh! But you get the idea.
                  >
                  > The rpm command has some --verify options in the query section for doing
                  > exactly this. Provided your RPM db hasn't been hacked.

                  Well, now that you mention it, up2date complains of a DB problem
                  whenever it tries to install a new package, but it hasn't seemed to have
                  affected the working of any of the software. Could this be an issue?

                  Chad
                • Cameron Simpson
                  ... Theoretically, yes, it could be symptomatic of a hack (or some other more innocent data corruption). But I doubt it. Let s presume it s more mundane for
                  Message 8 of 30 , Jun 8, 2003
                    On 23:37 07 Jun 2003, Chad Martin <chad@...> wrote:
                    | Cameron Simpson wrote:
                    | > On 22:25 07 Jun 2003, Mike Peters <mike@...> wrote:
                    | > | On Sat, 7 Jun 2003 22:18:20 +0300
                    | > | Mike Peters <mike@...> wrote:
                    | > | > (from your distro cd for example)
                    | > | Which wont work of course because the one on the cd will be a tgz or an
                    | > | rpm, Doh! But you get the idea.
                    | >
                    | > The rpm command has some --verify options in the query section for doing
                    | > exactly this. Provided your RPM db hasn't been hacked.
                    |
                    | Well, now that you mention it, up2date complains of a DB problem
                    | whenever it tries to install a new package, but it hasn't seemed to have
                    | affected the working of any of the software. Could this be an issue?

                    Theoretically, yes, it could be symptomatic of a hack (or some other
                    more innocent data corruption). But I doubt it. Let's presume it's more
                    mundane for now.

                    Can you try this:

                    strace -f crontab -e 2>strace.out

                    and post the result? Make a simple change to a command in the crontab
                    and save it. If the trace file is more than about 10k, perhaps you'd
                    better email it to me direct instead of the list.

                    Cheers,
                    --
                    Cameron Simpson <cs@...> DoD#743
                    http://www.cskk.ezoshosting.com/cs/

                    A ridiculous place! Leaping from one bump to another, 187 corners or whatever
                    it was! The number of times I've thanked God when I finished a lap there!
                    It gave you amazing satisfaction, no doubt about it, but anyone who says he
                    loved it is either a liar or wasn't going fast enough! - Jackie Stewart
                  • Chad Martin
                    ... OK. ... I m assuming that you wanted me to make an edit and save it, too, which I did. Since the output file is about 68k, I ll send it to you privately.
                    Message 9 of 30 , Jun 8, 2003
                      Cameron Simpson wrote:
                      > | Well, now that you mention it, up2date complains of a DB problem
                      > | whenever it tries to install a new package, but it hasn't seemed to have
                      > | affected the working of any of the software. Could this be an issue?
                      >
                      > Theoretically, yes, it could be symptomatic of a hack (or some other
                      > more innocent data corruption). But I doubt it. Let's presume it's more
                      > mundane for now.

                      OK.

                      > Can you try this:
                      >
                      > strace -f crontab -e 2>strace.out
                      >
                      > and post the result? Make a simple change to a command in the crontab
                      > and save it. If the trace file is more than about 10k, perhaps you'd
                      > better email it to me direct instead of the list.

                      I'm assuming that you wanted me to make an edit and save it, too, which
                      I did. Since the output file is about 68k, I'll send it to you privately.

                      Thanks for all your help!

                      Chad
                    • Cameron Simpson
                      Sorry for the delay - diagnosis below. ... Got it. Now I know what s happening. It s a slight bug in cron and a common and nasty bug in vim (your editor).
                      Message 10 of 30 , Jun 12, 2003
                        Sorry for the delay - diagnosis below.

                        On 21:45 08 Jun 2003, Chad Martin <chad@...> wrote:
                        | > Can you try this:
                        | >
                        | > strace -f crontab -e 2>strace.out
                        | >
                        | > and post the result? Make a simple change to a command in the crontab
                        | > and save it. If the trace file is more than about 10k, perhaps you'd
                        | > better email it to me direct instead of the list.
                        |
                        | I'm assuming that you wanted me to make an edit and save it, too, which
                        | I did. Since the output file is about 68k, I'll send it to you privately.

                        Got it.
                        Now I know what's happening.
                        It's a slight bug in cron and a common and nasty bug in vim (your editor).

                        Looking at the trace, we see:

                        execve("/usr/bin/crontab", ["crontab", "-e"], [/* 23 vars */]) = 0
                        [...]
                        open("/tmp/crontab.20085", O_RDWR|O_CREAT|O_EXCL, 0600) = 5
                        [...]
                        write(5, "30 4 1 1-11/2 * /usr/local/sbin/"..., 715) = 715

                        This is cron writing the temp file for you.
                        Note: it's using fd 5 for this.

                        [...]
                        fstat64(5, {st_mode=S_IFREG|0600, st_size=715, ...}) = 0

                        This is cron noting the size/timestampt of the file.

                        fork() = 20086
                        [pid 20085] wait4(-1, <unfinished ...>

                        Cron forking, mainline cron to pid 20085, child pid (soon to be
                        your editor) is 20086.

                        [pid 20086] execve("/bin/sh", ["/bin/sh", "-c", "/bin/vi /tmp/crontab.20085"], [/* 23 vars */]) = 0

                        Dispatch the editor in the child.
                        [... your editing happens in here ...]

                        and then you save the data. I infer from the behaviour that you
                        have vim's "backup" setting turned on (thankfully it's off by
                        default). Please say ":set" to your vi and check.
                        While it sounds like a good idea, vim's implementation is bad.

                        vim's backup mode works by renaming your file to a backup name, writing a fresh one
                        with the new data, then removing the old (renamed) file if that worked:

                        [pid 20086] unlink("crontab.20085~") = -1 ENOENT (No such file or directory)

                        That's removing any old backup just in case.

                        [pid 20086] rename("crontab.20085", "crontab.20085~") = 0

                        Rename your original file.

                        [pid 20086] open("crontab.20085", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3
                        [pid 20086] write(3, "# Comment\n30 4 1 1-11/2 * /usr/l"..., 725) = 725
                        [pid 20086] close(3) = 0

                        Write the new data to a brand new "crontab.20085".

                        [pid 20086] unlink("crontab.20085~") = 0

                        That went ok, remove the original and then exit.

                        <... wait4 resumed> [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 20086
                        --- SIGCHLD (Child exited) ---
                        fstat64(5, {st_mode=S_IFREG|0600, st_size=715, ...}) = 0
                        write(2, "crontab: no changes made to cron"..., 36crontab: no changes made to crontab
                        ) = 36
                        unlink("/tmp/crontab.20085") = 0

                        This is cron fstat64()ing fd 5, which is still atatched the the
                        ORIGINAL file, which never got changed, just renamed.

                        So there are two problems here:

                        - cron is stat()ing the original file from its old hook to it
                        and not seeing the changes because vim doesn't change that file

                        - vim is being really bloody STUPID
                        what did you ask to do? "edit this file please"
                        what did it do? "I'll just put your file over here and put this
                        replacement where you left it!"

                        The workaround is to turn of "backup" mode in vim, which will prevent
                        it screwing you over like this. The fix is to run far far away from vim
                        because its authors must be idiots. The _correct_ way to take a backup
                        is to take a backup - make a backup COPY and then rewrite the original.

                        The loathesome practice of unlinking the original and writing a fresh
                        file breaks: permissions, ownerships, open file handles (which is what
                        got the crontab command), hard links, soft links, etc etc. It is almost
                        universally a Very Bad Idea and it's also very common.

                        I hope this fixes your problem.

                        Cheers,
                        --
                        Cameron Simpson <cs@...> DoD#743
                        http://www.cskk.ezoshosting.com/cs/

                        SCCS, the source motel! Programs check in and never check out! - Ken Thompson
                      • Chad Martin
                        ... Not a problem. I m getting much more than I m paying for. ;) ... Alright, I may not be clear on this, but I pulled up vi, both with the ... backspace=2
                        Message 11 of 30 , Jun 16, 2003
                          Cameron Simpson wrote:
                          > Sorry for the delay - diagnosis below.

                          Not a problem. I'm getting much more than I'm paying for. ;)

                          > Dispatch the editor in the child.
                          > [... your editing happens in here ...]
                          >
                          > and then you save the data. I infer from the behaviour that you
                          > have vim's "backup" setting turned on (thankfully it's off by
                          > default). Please say ":set" to your vi and check.
                          > While it sounds like a good idea, vim's implementation is bad.

                          Alright, I may not be clear on this, but I pulled up vi, both with the
                          crontab -e call and just vi, and when I type :set, I get the following:

                          --- Options ---
                          backspace=2 history=50 ttyfast
                          Hit ENTER or type command to continue

                          None of this seems to indicate that the backup setting is on. If it
                          were on, would it show up here? What command would I type to turn it
                          off at this point? Typing "backup" doesn't seem to be what vim wants.

                          > The workaround is to turn of "backup" mode in vim, which will prevent
                          > it screwing you over like this. The fix is to run far far away from vim
                          > because its authors must be idiots. The _correct_ way to take a backup
                          > is to take a backup - make a backup COPY and then rewrite the original.

                          OK, assuming that we can't figure out the issues with vim, is there any
                          simple way to change the editor called through crontab to, say, pico?
                          If all else fails, can I just edit the spool file directly and touch the
                          cron directory, as you mentioned in previous emails?

                          Thanks for all your help so far!

                          Chad Martin
                        • Scott Robbins
                          ... You might check /etc/.vimrc (sometimes .VIMRC. Or make any kind of text file with vi, then edit it and see if you have two--eg test.txt and test.txt~. ...
                          Message 12 of 30 , Jun 16, 2003
                            On Mon, Jun 16, 2003 at 06:43:32PM -0500, Chad Martin wrote:
                            > Cameron Simpson wrote:
                            > > Sorry for the delay - diagnosis below.
                            >
                            > > Dispatch the editor in the child.
                            > > [... your editing happens in here ...]
                            > >
                            > > and then you save the data. I infer from the behaviour that you
                            > > have vim's "backup" setting turned on (thankfully it's off by
                            > > default). Please say ":set" to your vi and check.
                            > > While it sounds like a good idea, vim's implementation is bad.
                            >
                            >
                            > None of this seems to indicate that the backup setting is on. If it
                            > were on, would it show up here? What command would I type to turn it
                            > off at this point? Typing "backup" doesn't seem to be what vim wants.

                            You might check /etc/.vimrc (sometimes .VIMRC. Or make any kind of text
                            file with vi, then edit it and see if you have two--eg test.txt and
                            test.txt~.

                            >
                            > OK, assuming that we can't figure out the issues with vim, is there any
                            > simple way to change the editor called through crontab to, say, pico?
                            > If all else fails, can I just edit the spool file directly and touch the
                            > cron directory, as you mentioned in previous emails?

                            I would think that (I haven't been following this thread) that either
                            temporarily changing your default editor to pico or simply typing pico
                            and the file you want to edit would work, such as pico /tmp/crontab

                            Hopefully, my not following this thread from the beginning doesn't make
                            that a stupid irrelevant answer--if it does, I apologize.

                            --

                            Scott Robbins

                            PGP keyID EB3467D6
                            ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 D575 EB34 67D6 )
                            gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

                            Spike: What, your Mom doesn't know?
                            Joyce: Know what?
                            Buffy: That I'm, uh...in a band. A rock band...with Spike here.
                            Spike: Right. She plays the-the triangle...
                            Buffy: Drums.
                            Spike: Drums, yeah. She's hell on the old skins, you know.
                            Joyce: (to Spike) And what do you do?
                            Spike: Well I sing.


                            [Non-text portions of this message have been removed]
                          • Chad Martin
                            ... Sound like good ideas. ... I m not sure what one needs to do to change their default editor in a non-X Linux box. Secondly, the issue is coming up when I
                            Message 13 of 30 , Jun 16, 2003
                              Scott Robbins wrote:
                              > You might check /etc/.vimrc (sometimes .VIMRC. Or make any kind of text
                              > file with vi, then edit it and see if you have two--eg test.txt and
                              > test.txt~.

                              Sound like good ideas.

                              >>OK, assuming that we can't figure out the issues with vim, is there any
                              >>simple way to change the editor called through crontab to, say, pico?
                              >>If all else fails, can I just edit the spool file directly and touch the
                              >>cron directory, as you mentioned in previous emails?
                              >
                              > I would think that (I haven't been following this thread) that either
                              > temporarily changing your default editor to pico or simply typing pico
                              > and the file you want to edit would work, such as pico /tmp/crontab

                              I'm not sure what one needs to do to change their default editor in a
                              non-X Linux box. Secondly, the issue is coming up when I type crontab
                              -e to edit my crontab. This creates a new file in the /tmp directory,
                              opens vi to edit it, then destroys the temp file after the editing is
                              done. The only file I can edit directly with pico in this case is the
                              crontab file found in my /var/spool directory, which has very stern
                              comments in it against that very thing.

                              Chad Martin
                            • Chad Martin
                              I apologize to all for not just trying it before sending the last email. ... ls /etc/.v* and ls /etc/.V* both return no files. Secondly, I created a simple
                              Message 14 of 30 , Jun 16, 2003
                                I apologize to all for not just trying it before sending the last email.

                                Scott Robbins wrote:
                                > You might check /etc/.vimrc (sometimes .VIMRC. Or make any kind of text
                                > file with vi, then edit it and see if you have two--eg test.txt and
                                > test.txt~.

                                ls /etc/.v*
                                and
                                ls /etc/.V*
                                both return no files.

                                Secondly, I created a simple text file and edited and saved it a few
                                times, and a backup file was never created, further indicating that my
                                backup option is off in vim.

                                Chad Martin
                              • Scott Robbins
                                ... Hrrm, I thought it was simply set editor but that s not working in FreeBSD with zsh. I m sure it s simple. (Does a quick deja search) Hrrm, see if it s
                                Message 15 of 30 , Jun 16, 2003
                                  On Mon, Jun 16, 2003 at 07:07:09PM -0500, Chad Martin wrote:
                                  > Scott Robbins wrote:
                                  > >


                                  > > I would think that (I haven't been following this thread) that either
                                  > > temporarily changing your default editor to pico or simply typing pico
                                  > > and the file you want to edit would work, such as pico /tmp/crontab
                                  >
                                  > I'm not sure what one needs to do to change their default editor in a
                                  > non-X Linux box. Secondly, the issue is coming up when I type crontab
                                  > -e to edit my crontab. This creates a new file in the /tmp directory,
                                  > opens vi to edit it, then destroys the temp file after the editing is
                                  > done. The only file I can edit directly with pico in this case is the
                                  > crontab file found in my /var/spool directory, which has very stern
                                  > comments in it against that very thing.


                                  Hrrm, I thought it was simply set editor but that's not working in
                                  FreeBSD with zsh. I'm sure it's simple. (Does a quick deja search)

                                  Hrrm, see if it's in .bash_profile or .bashrc (In FreeBSD, it's in
                                  .profile)

                                  Aha, ok, how about...

                                  export EDITOR=/usr/bin/pico

                                  (The posting I found says to do that in .profile--if that's the case,
                                  you'll probably have to log out and log back in. Then, when done, change
                                  it back.)

                                  HTH (but not sure)

                                  --

                                  Scott Robbins

                                  PGP keyID EB3467D6
                                  ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 D575 EB34 67D6 )
                                  gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

                                  Giles: It's a trick. They get inside my head, make me see
                                  things I want.
                                  Xander: Then why would they make you see me?
                                  Giles: You're right. Let's go.


                                  [Non-text portions of this message have been removed]
                                • Cameron Simpson
                                  ... Hmm. (I use nvi, so I fired up vim as vim.) It seems that when you run vim as vim it reports lots of settings. If you run vim as vi, ... instead. It should
                                  Message 16 of 30 , Jun 16, 2003
                                    On 18:43 16 Jun 2003, Chad Martin <chad@...> wrote:
                                    | Cameron Simpson wrote:
                                    | > Dispatch the editor in the child.
                                    | > [... your editing happens in here ...]
                                    | >
                                    | > and then you save the data. I infer from the behaviour that you
                                    | > have vim's "backup" setting turned on (thankfully it's off by
                                    | > default). Please say ":set" to your vi and check.
                                    | > While it sounds like a good idea, vim's implementation is bad.
                                    |
                                    | Alright, I may not be clear on this, but I pulled up vi, both with the
                                    | crontab -e call and just vi, and when I type :set, I get the following:
                                    |
                                    | --- Options ---
                                    | backspace=2 history=50 ttyfast
                                    | Hit ENTER or type command to continue
                                    | None of this seems to indicate that the backup setting is on. If it
                                    | were on, would it show up here? What command would I type to turn it
                                    | off at this point?

                                    Hmm. (I use nvi, so I fired up vim as vim.) It seems that when you
                                    run vim as vim it reports lots of settings. If you run vim as vi,
                                    it reports just the useless stuff you show. Go:

                                    :set all

                                    instead. It should be visible then.

                                    | Typing "backup" doesn't seem to be what vim wants.

                                    Well first we need to check if the setting is on.
                                    Then:

                                    :set nobackup

                                    should disable it. Check it in your /usr/share/vim/vimrc file
                                    and personal ~/.vimrc (well, root's ~/.vimrc) as well.

                                    | > The workaround is to turn of "backup" mode in vim, which will prevent
                                    | > it screwing you over like this. The fix is to run far far away from vim
                                    | > because its authors must be idiots. The _correct_ way to take a backup
                                    | > is to take a backup - make a backup COPY and then rewrite the original.
                                    |
                                    | OK, assuming that we can't figure out the issues with vim,

                                    It is better to fix vim's behaviour.

                                    | is there any
                                    | simple way to change the editor called through crontab to, say, pico?

                                    Well, crontab and most other things listen to $EDITOR, so you could set it to
                                    pico or nvi (you'd need to fetch nvi) or whatever.

                                    For just crontab you could write either a shell alias or a wrapper script:

                                    alias crontab='EDITOR=pico /usr/bin/crontab \*'

                                    #!/bin/sh
                                    EDITOR=pico
                                    export EDITOR
                                    exec /usr/bin/crontab ${1+"$@"}

                                    | If all else fails, can I just edit the spool file directly and touch the
                                    | cron directory, as you mentioned in previous emails?

                                    Yes, but that's very ugly and painful.

                                    Cheers,
                                    --
                                    Cameron Simpson <cs@...> DoD#743
                                    http://www.cskk.ezoshosting.com/cs/

                                    Every \item command in item_list must have an optional argument.
                                    - Leslie Lamport, LaTeX
                                  • Chad Martin
                                    ... vim isn t in root s path, but vi pulls up vim. Anyway, :set all shows nobackup, what s more, here s the other relavent stuff: nobackup backupcopy=auto
                                    Message 17 of 30 , Jun 16, 2003
                                      Cameron Simpson wrote:
                                      > Hmm. (I use nvi, so I fired up vim as vim.) It seems that when you
                                      > run vim as vim it reports lots of settings. If you run vim as vi,
                                      > it reports just the useless stuff you show. Go:
                                      >
                                      > :set all
                                      >
                                      > instead. It should be visible then.

                                      vim isn't in root's path, but vi pulls up vim. Anyway, :set all shows
                                      nobackup, what's more, here's the other relavent stuff:

                                      nobackup
                                      backupcopy=auto
                                      backupext=~
                                      backupskip=/tmp/*

                                      It seems like it shouldn't be backing up anything in my /tmp directory
                                      anyway, even if backup is on.

                                      > Well first we need to check if the setting is on.
                                      > Then:
                                      >
                                      > :set nobackup

                                      I ran that, but it still doesn't work.

                                      > should disable it. Check it in your /usr/share/vim/vimrc file
                                      > and personal ~/.vimrc (well, root's ~/.vimrc) as well.

                                      Neither of these files exist. There a vimrc_example.vim file in
                                      /usr/share/vim/vim61 but that's about it.

                                      > It is better to fix vim's behaviour.

                                      OK, but vim seems pretty conviced it's behaving properly.

                                      Chad Martin
                                    Your message has been successfully submitted and would be delivered to recipients shortly.