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

Re: Output/Input is not to/from a terminal

Expand Messages
  • Andrew Pimlott
    ... I had no idea this was a todo, and I didn t look at your implementation, but I ve done this. I use a wrapper script to map some file descriptors, and a
    Message 1 of 6 , Apr 30, 2003
    • 0 Attachment
      On Wed, Apr 30, 2003 at 02:11:59PM +0100, Walter Briscoe wrote:
      > :help todo contains
      > 7 Allow using Vim in a pipe: "ls | vim -u xxx.vim - | yyy". Only needs
      > implementing ":w" to stdout in the buffer that was read from stdin.

      I had no idea this was a todo, and I didn't look at your
      implementation, but I've done this. I use a wrapper script to map
      some file descriptors, and a vim script to write the stdin buffer
      when it's unloaded. It's a quick hack, but do you see any problem
      with it is principle?

      I made :bunload, not :w, write the buffer to stdout, since my
      intuition is that you're only "happy" with the buffer when you close
      it. Plus, I :w habitually, and wouldn't want this to write to
      stdout. What would happen if you :w twice?

      vif:

      #!/bin/sh

      OPTS=$(getopt -o xg -n vif --long xterm,gui -- "$@")
      eval set -- "$OPTS"

      VIM='vim --cmd "runtime filter.vim"'
      CMD="$VIM -"

      while true; do
      case $1 in
      -x|--xterm) CMD="xterm -e sh -c '$VIM - <&4' 4<&0"; shift ;;
      -g|--gui) CMD="$VIM -g -"; shift ;;
      --) shift ; break ;;
      esac
      done

      eval exec $CMD 3>&1 >&2

      filter.vim:

      autocmd StdinReadPost * set buftype=nowrite | let b:stdin_buf = 1
      autocmd BufUnload * call Maybe_output()

      function Maybe_output()
      if ! exists("b:stdin_buf")
      return
      endif

      w! /dev/fd/3
      endfunction

      One obvious lack in vim (as far as I can tell) is a way to make an
      autocommand apply only to the current buffer. This is a particular
      problem when the buffer is unnamed. b:stdin_buf is used solely to
      work around this.

      (Actually, in writing this message, I found a bug. If the buffer is
      unloaded but vim is not exiting, the buffer variable is already
      cleared when the autocmd is called. So my b:stdin_buf work-around
      fails. Could the autocmd be called before variables are cleared?
      Or do I misunderstand what happens? Maybe I should set a global
      variable to the stdin bufno instead, and check that.)

      Andrew
    • Walter Briscoe
      In message of Wed, 30 Apr 2003 22:02:22 in , Bram Moolenaar writes ... I shall abandon this. I
      Message 2 of 6 , May 1, 2003
      • 0 Attachment
        In message <200304302002.h3UK2M708164@...> of Wed, 30 Apr 2003
        22:02:22 in , Bram Moolenaar <Bram@...> writes
        >
        >Walter Briscoe wrote:
        >
        >> :help todo contains
        >> 7 Allow using Vim in a pipe: "ls | vim -u xxx.vim - | yyy". Only needs
        >> implementing ":w" to stdout in the buffer that was read from stdin.
        >>
        >> I did a quick and dirty proof of concept on this. It worked once in
        >> w2ksp3 with a vimd built with Make_ivc.mak. It does not work with gvimd
        >> because stdout is unsupported by windoze programs.
        >> The command which worked was
        >> C:\wfb\vim\bld\vim62a\src> echo hello| vimd "+set ff=unix" +x - > t.x
        >
        >It's a nice hack, but it's not nearly enough. You also need to take
        >care of temp files, these still need to be written to a real file. And
        >things like the gzip plugin. This requires thinking of how to tell Vim
        >it should write to stdout instead of a file.
        >
        >There are more important things to work on before adding another
        >half-done feature...
        >
        I shall abandon this.
        I leave the missing documentation and/or message change to Bram.
        --
        Walter Briscoe
      • Walter Briscoe
        In message of Wed, 30 Apr 2003 22:39:53 in , Andrew Pimlott writes ... [snip] This work is in
        Message 3 of 6 , May 1, 2003
        • 0 Attachment
          In message <20030501023953.GP30778@...> of Wed, 30 Apr 2003
          22:39:53 in , Andrew Pimlott <vim-dev@...> writes
          >On Wed, Apr 30, 2003 at 02:11:59PM +0100, Walter Briscoe wrote:
          >> :help todo contains
          >> 7 Allow using Vim in a pipe: "ls | vim -u xxx.vim - | yyy". Only needs
          >> implementing ":w" to stdout in the buffer that was read from stdin.
          >
          >I had no idea this was a todo, and I didn't look at your
          >implementation, but I've done this. I use a wrapper script to map
          >some file descriptors, and a vim script to write the stdin buffer
          >when it's unloaded. It's a quick hack, but do you see any problem
          >with it is principle?
          >
          >I made :bunload, not :w, write the buffer to stdout, since my
          >intuition is that you're only "happy" with the buffer when you close
          >it. Plus, I :w habitually, and wouldn't want this to write to
          >stdout. What would happen if you :w twice?
          [snip]
          This work is in a narrower context than vim itself which interested me.
          It looks good to me. It was interesting to see getopt (singular name)
          deal with long option names. I think IEEE Std 1003.1-2001 does not have
          getopt in that context. It has getopts (plural name) without the ability
          to handle long option names.
          --
          Walter Briscoe
        • Andrew Pimlott
          ... Oh, I m sure it is a GNU-ism. I cribbed the use of getopt from a file getopt-parse.bash.gz that got installed in an examples directory of util-linux on
          Message 4 of 6 , May 2, 2003
          • 0 Attachment
            On Fri, May 02, 2003 at 07:21:06AM +0100, Walter Briscoe wrote:
            > It was intresting to see getopt (singular name)
            > deal with long option names. I think IEEE Std 1003.1-2001 does not have
            > getopt in that context. It has getopts (plural name) without the ability
            > to handle long option names.

            Oh, I'm sure it is a GNU-ism. I cribbed the use of getopt from a
            file "getopt-parse.bash.gz" that got installed in an examples
            directory of util-linux on my (Debian) system. I'd never used any
            form of getopt* in a shell script.

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