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

Re: :X command

Expand Messages
  • Chase Tingley
    ... The discussion of disabling the :X command reminded me of a hilarious story involving a somewhat younger me, a friend of mine, a lengthy header file for
    Message 1 of 4 , Jan 30, 2001
    • 0 Attachment
      > > > The build-in commands take precedence. This is noted in the docs.
      > >
      > > So, how do I disable :X then? :-)
      >
      > 1. Remove the X key from your keyboard
      > 2. Get hypnotized to panic and switch off the computer when you only think
      > of typing :X
      > 3. Edit src/ex_docmd.c and make the ex_X() function empty, recompile.
      > 4. Use Emacs
      > 5. Disable the crypt feature in src/feature.h and recompile

      The discussion of disabling the :X command reminded me of a hilarious story
      involving a somewhat younger me, a friend of mine, a lengthy header file
      for his introductory CS class final project, my incomplete knowledge of vi,
      and repeated attempts to <ESC>/<CTRL-C> my way out of the key prompt (which
      unlike vim's apparently didn't take <CTRL-C> for an answer). Later, I
      managed to recreate most of the file from memory, then ran failed compiles
      against it until I figured out the rest.

      The more serious of Bram's suggestions about disabling :X all rely on
      recompiling, which isn't really that great for a multi-user environment --
      some people may want to be able to use :X, but the majority of users may
      never want to see it. Why not have a boolean "encrypt" option? It
      defaults to true, and people can "set noencrypt" to turn disable :X.
      (Alternately, an administrator could "set noencrypt" system-wide, and let
      users re-enable it as they desire.)

      This would be easy. I guess there's a question of exactly what the option
      would control -- whether it just disables :X (which only sets a key), or
      also disables the encryption on write that happens when the key is set.
      Also, what happens if an encrypted file is opened while "encrypt" is turned
      off? (Presumably you get a prompt as normal and aren't forced to read the
      encrypted version...)

      ct
    • Bram Moolenaar
      ... My point is that you should not disable a command. If someone types :X accidentally, he needs a way to get out without causing damage. There is an item
      Message 2 of 4 , Jan 31, 2001
      • 0 Attachment
        Chase Tingley wrote:

        > The more serious of Bram's suggestions about disabling :X all rely on
        > recompiling, which isn't really that great for a multi-user environment --
        > some people may want to be able to use :X, but the majority of users may
        > never want to see it. Why not have a boolean "encrypt" option? It
        > defaults to true, and people can "set noencrypt" to turn disable :X.
        > (Alternately, an administrator could "set noencrypt" system-wide, and let
        > users re-enable it as they desire.)
        >
        > This would be easy. I guess there's a question of exactly what the option
        > would control -- whether it just disables :X (which only sets a key), or
        > also disables the encryption on write that happens when the key is set.
        > Also, what happens if an encrypted file is opened while "encrypt" is turned
        > off? (Presumably you get a prompt as normal and aren't forced to read the
        > encrypted version...)

        My point is that you should not disable a command. If someone types :X
        accidentally, he needs a way to get out without causing damage. There
        is an item in the todo list to require the password to be typed twice,
        and refuse it when it's not identical. I think that should be
        sufficient. It's not 100% backwards compatible, but I don't think that
        is a problem in this case, since you are always typing the password.

        --
        From "know your smileys":
        <<<:-{ Worf (Never smiles anyways, so he's a bad smiley)

        /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
        ((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
        \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
      • Chase Tingley
        On Wed, 31 Jan 2001, Bram Moolenaar wrote:If someone types :X accidentally, he needs a way to get out without causing damage. There is an item in the
        Message 3 of 4 , Jan 31, 2001
        • 0 Attachment
          On Wed, 31 Jan 2001, Bram Moolenaar wrote:

          > If someone types :X accidentally, he needs a way to get out without
          > causing damage. There is an item in the todo list to require the
          > password to be typed twice, and refuse it when it's not identical. I
          > think that should be sufficient. It's not 100% backwards compatible, but
          > I don't think that is a problem in this case, since you are always typing
          > the password.

          I took a rough swing at implementing this (attached).

          Also, I'm pretty sure (though not 100%) that get_crypt_key() was leaking
          "p" when TRUE was given as the value of "store" -- set_option_value() would
          save a copy and the original p allocated by getcmdline_prompt() would
          wander off into the ether. Hopefully I'm not missing something or
          hallucinating this; I tentatively stuck an extra vim_free in the patch to
          deal with it.

          ct
        • Bram Moolenaar
          ... Very good. Hmm, I think the call in main() to get the crypt key also should ask twice. I ll change it a bit. ... Looks like you are right. Thanks for a
          Message 4 of 4 , Jan 31, 2001
          • 0 Attachment
            Chase Tingley wrote:

            > I took a rough swing at implementing this (attached).

            Very good. Hmm, I think the call in main() to get the crypt key also should
            ask twice. I'll change it a bit.

            > Also, I'm pretty sure (though not 100%) that get_crypt_key() was leaking
            > "p" when TRUE was given as the value of "store" -- set_option_value() would
            > save a copy and the original p allocated by getcmdline_prompt() would
            > wander off into the ether. Hopefully I'm not missing something or
            > hallucinating this; I tentatively stuck an extra vim_free in the patch to
            > deal with it.

            Looks like you are right.

            Thanks for a useful reply to this discussion!

            --
            hundred-and-one symptoms of being an internet addict:
            92. It takes you two hours to check all 14 of your mailboxes.

            /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
            ((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
            \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
          Your message has been successfully submitted and would be delivered to recipients shortly.