scp completion options

scp completion options

[David Woodfall]

Hi

When I tab complete a scp command such as:

scp somefile host:somefolder<tab>

I will always get the current local directory as the first completion
option if it is any way similar to the name of the remote. Is there a
way to stop that behaviour and list remote directories first if I'm
scp'ing /to/ a host? In fact I will always have the local directory
listed whatever I do.

I've tried setting some directory order in a completion but I'm not
sure I got it right. It didn't change anything anyway.

Any help on making scp completion smarter would be appreciated.

-Dave

--

There are no threads in a.b.p.erotica,  so there's no  gain in using a
threaded news reader.
  -- unknown source

                                                            .--.  oo
                                                           (____)//
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~'

Re: scp completion options

[Peter Stephenson]

On Wed, 27 Jun 2018 00:06:54 +0100
David Woodfall <dave@dawoodfall.net> wrote:
> When I tab complete a scp command such as:
> 
> scp somefile host:somefolder<tab>
> 
> I will always get the current local directory as the first completion
> option if it is any way similar to the name of the remote. Is there a
> way to stop that behaviour and list remote directories first if I'm
> scp'ing /to/ a host? In fact I will always have the local directory
> listed whatever I do.

Hmm... you *should* be able to do something like what's below (which is
rather simplistic, as a demo).  The idea is: if you're on the third word
or after, and the second word didn't have a ":" (so is assumed to be a
local file), then only complete remotely.

But actually I don't see how to get this to work in the case you're
talking about (hence the question marks), because the tag for remote
files is just 'files' so will allow it to complete local files.  This
looks to me like a mistake, and _remote_files should arrange for a
different tag.

I may be missing something, but if I'm not, changing _remote_files ought
to be easy.  There may also be other ways of limiting completion, but
the point remains.


scp_comp_helper() {
  if [[ CURRENT -gt 2 && $words[2] != *:* && ]]; then
    # Complete remotely only...?
    reply=('hosts ????')
  else
    reply=('hosts files')
  fi
}
zstyle -e ':completion:*:complete:scp:*:' tag-order scp_comp_helper


pws

Re: scp completion options

[David Woodfall]

On Wednesday 27 June 2018 09:15,
Peter Stephenson <p.stephenson@samsung.com> put forth the proposition:
> On Wed, 27 Jun 2018 00:06:54 +0100
> David Woodfall <dave@dawoodfall.net> wrote:
> > When I tab complete a scp command such as:
> >
> > scp somefile host:somefolder<tab>
> >
> > I will always get the current local directory as the first completion
> > option if it is any way similar to the name of the remote. Is there a
> > way to stop that behaviour and list remote directories first if I'm
> > scp'ing /to/ a host? In fact I will always have the local directory
> > listed whatever I do.
>
> Hmm... you *should* be able to do something like what's below (which is
> rather simplistic, as a demo).  The idea is: if you're on the third word
> or after, and the second word didn't have a ":" (so is assumed to be a
> local file), then only complete remotely.
>
> But actually I don't see how to get this to work in the case you're
> talking about (hence the question marks), because the tag for remote
> files is just 'files' so will allow it to complete local files.  This
> looks to me like a mistake, and _remote_files should arrange for a
> different tag.
>
> I may be missing something, but if I'm not, changing _remote_files ought
> to be easy.  There may also be other ways of limiting completion, but
> the point remains.
>
>
> scp_comp_helper() {
>   if [[ CURRENT -gt 2 && $words[2] != *:* && ]]; then
>     # Complete remotely only...?
>     reply=('hosts ????')
>   else
>     reply=('hosts files')
>   fi
> }
> zstyle -e ':completion:*:complete:scp:*:' tag-order scp_comp_helper

That's giving me an error on the 'if' line:

custom:597: parse error near `;'

--

Convention organizer to Linus Torvalds: "You might like to come with us
to some licensed[1] place, and have some pizza."

Linus: "Oh, I did not know that you needed a license to eat pizza".

[1] Licenced - refers in Australia to a restaurant which has government
licence to sell liquor.
  -- Linus at a talk at the Melbourne University

                                                            .--.  oo
                                                           (____)//
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~'

Re: scp completion options

[Peter Stephenson]

On Wed, 27 Jun 2018 11:13:12 +0100
David Woodfall <dave@dawoodfall.net> wrote:
> > scp_comp_helper() {
> >   if [[ CURRENT -gt 2 && $words[2] != *:* && ]]; then
> >     # Complete remotely only...?
> >     reply=('hosts ????')
> >   else
> >     reply=('hosts files')
> >   fi
> > }
> > zstyle -e ':completion:*:complete:scp:*:' tag-order
> > scp_comp_helper  
> 
> That's giving me an error on the 'if' line:

You need to get rid of the second && --- I originally had another test
I thought better of but didn't get rid of in the version I copied
into the e-mail, so it wasn't quite what I actually tried out.

As no-one has come up with anything better I may play with changing
_remote_files to use the tag remote-files and see if that helps.

pws

Re: scp completion options

[David Woodfall]

On Thursday 28 June 2018 09:38,
Peter Stephenson <p.stephenson@samsung.com> put forth the proposition:
> On Wed, 27 Jun 2018 11:13:12 +0100
> David Woodfall <dave@dawoodfall.net> wrote:
> > > scp_comp_helper() {
> > >   if [[ CURRENT -gt 2 && $words[2] != *:* && ]]; then
> > >     # Complete remotely only...?
> > >     reply=('hosts ????')
> > >   else
> > >     reply=('hosts files')
> > >   fi
> > > }
> > > zstyle -e ':completion:*:complete:scp:*:' tag-order
> > > scp_comp_helper
> >
> > That's giving me an error on the 'if' line:
>
> You need to get rid of the second && --- I originally had another test
> I thought better of but didn't get rid of in the version I copied
> into the e-mail, so it wasn't quite what I actually tried out.
>
> As no-one has come up with anything better I may play with changing
> _remote_files to use the tag remote-files and see if that helps.
>
> pws
>
>

Thanks. It seems to do the trick.

I've still to discover why sometimes remote names get escape for no
apparent reason. eg I have a patch on the remote named:

0001-fix-typo-in-rc.geomyidae-slackware-init-script.patch

This is the first item completed after hitting tab, but it is listed
as

^[k*^[\0001-fix-typo-in-rc.geomyidae-slackware-init-script.patch

in the completion menu, and like

\$\'\\033\'k\\\*\$\'\\033\'\\\\0001-fix-typo-in-rc.geomyidae-slackware-init-script.patch

On the command line after the 'host:'

It's obviously an escape code, and I do use a few, but I can't find
anything with a 'k' or *$ in it.

-Dave

--

Not me, guy.  I read the Bash man page each day like a Jehovah's Witness reads
the Bible.  No wait, the Bash man page IS the bible.  Excuse me...
  -- More on confusing aliases, taken from comp.os.linux.misc

                                                            .--.  oo
                                                           (____)//
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~'

Re: scp completion options

[Bart Schaefer]

On Thu, Jun 28, 2018 at 1:14 PM, David Woodfall <dave@dawoodfall.net> wrote:
>
> I've still to discover why sometimes remote names get escape for no
> apparent reason. eg I have a patch on the remote named:
>
> 0001-fix-typo-in-rc.geomyidae-slackware-init-script.patch
>
> This is the first item completed after hitting tab, but it is listed
> as
>
> ^[k*^[\0001-fix-typo-in-rc.geomyidae-slackware-init-script.patch

This is probably something being spat out by your shell startup on the
remote host.  Go through your .zshenv, .zshrc, etc. (or equivalent
files for other shell) on the remote host and make sure that nothing
writes output such as terminal control sequences when the standard
input is not a tty.  (It could also be something in /etc/zshenv in
which case you're probably stuck unless you can become root on the
remote host.)

Re: scp completion options

[David Woodfall]

On Thursday 28 June 2018 13:26,
Bart Schaefer <schaefer@brasslantern.com> put forth the proposition:
> On Thu, Jun 28, 2018 at 1:14 PM, David Woodfall <dave@dawoodfall.net> wrote:
> >
> > I've still to discover why sometimes remote names get escape for no
> > apparent reason. eg I have a patch on the remote named:
> >
> > 0001-fix-typo-in-rc.geomyidae-slackware-init-script.patch
> >
> > This is the first item completed after hitting tab, but it is listed
> > as
> >
> > ^[k*^[\0001-fix-typo-in-rc.geomyidae-slackware-init-script.patch
>
> This is probably something being spat out by your shell startup on the
> remote host.  Go through your .zshenv, .zshrc, etc. (or equivalent
> files for other shell) on the remote host and make sure that nothing
> writes output such as terminal control sequences when the standard
> input is not a tty.  (It could also be something in /etc/zshenv in
> which case you're probably stuck unless you can become root on the
> remote host.)

Things I've tested so far:

I set my shell on the remote to bash. (It doesn't have anything
custom setup for bash because the server (slackware 14.2) is rather
newish and I haven't bothered.)

I unset LS_COLORS and LS_OPTIONS on remote and local (including
ZLS_COLORS on the local.)

I went through my local zsh files (but not system-wide yet) and
turned off anything that looked remotely 'colourish'.

I tried it outside of screen.

I tried it in xterm (I normally use urxvt).

No change.

Stumped at the moment.

--


                                                            .--.  oo
                                                           (____)//
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~'

Re: scp completion options

[Bart Schaefer]

On Thu, Jun 28, 2018 at 1:56 PM, David Woodfall <dave@dawoodfall.net> wrote:
>
> Things I've tested so far:
>
> [...]

_remote_files is most likely running
  ssh -o BatchMode=yes -a -x $host ls -d1FL --
where $host is obviously the remote name.  Try running that directly
from your command line and see what you get.

Try again replacing "ls" with /bin/ls just in case an alias is somehow
being invoked, or find out if you have some other "ls" in the default
search path.

Re: scp completion options

[David Woodfall]

On Thursday 28 June 2018 17:31,
Bart Schaefer <schaefer@brasslantern.com> put forth the proposition:
> On Thu, Jun 28, 2018 at 1:56 PM, David Woodfall <dave@dawoodfall.net> wrote:
> >
> > Things I've tested so far:
> >
> > [...]
>
> _remote_files is most likely running
>   ssh -o BatchMode=yes -a -x $host ls -d1FL --
> where $host is obviously the remote name.  Try running that directly
> from your command line and see what you get.
>
> Try again replacing "ls" with /bin/ls just in case an alias is somehow
> being invoked, or find out if you have some other "ls" in the default
> search path.

Still no go I'm afraid. I also edited
/etc/profile.d/coreutils-dircolors.sh and made color=never the
default option.

I tried /bin/ls and /usr/bin/ls

Funnily enough when I first tried that and forgot to change $host to
the actual hostname it still listed the remote files/dirs.

If I choose a subdir on the remote it seems to always list the
current dir on the local, and it has those annoying escapes too.

Weird.

I'm going to have to start dissecting my local zsh files I think.

--

Audience: What will become of Linux when the Hurd is ready?
Eric Youngdale: Err... is Richard Stallman here?
  -- From the Linux conference in spring '95, Berlin

                                                            .--.  oo
                                                           (____)//
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~'

Re: scp completion options

[Peter Stephenson]

On Wed, 27 Jun 2018 09:15:14 +0100
Peter Stephenson <p.stephenson@samsung.com> wrote:
>..,
> But actually I don't see how to get this to work in the case you're
> talking about (hence the question marks), because the tag for remote
> files is just 'files' so will allow it to complete local files.  This
> looks to me like a mistake, and _remote_files should arrange for a
> different tag.
> 
> I may be missing something, but if I'm not, changing _remote_files
> ought to be easy.

This does appear to do the trick.  I propose to submit this.

pws

diff --git a/Completion/Unix/Type/_remote_files b/Completion/Unix/Type/_remote_files
index a5fce9a..267715a 100644
--- a/Completion/Unix/Type/_remote_files
+++ b/Completion/Unix/Type/_remote_files
@@ -75,9 +75,9 @@ if zstyle -T ":completion:${curcontext}:files" remote-access; then
     remdispf=( ${(M)remdispf:#${~glob[2]}} )
   fi
 
-  _tags files
+  _tags remote-files
   while _tags; do
-    while _next_label files expl ${suf:-remote directory}; do
+    while _next_label remote-files expl ${suf:-remote directory}; do
       [[ -n $suf ]] &&
           compadd "$args[@]" "$expl[@]" -d remdispf -- ${(q)remdispf%[*=|]} && ret=0
       compadd ${suf:+-S/} -r "/ \t\n\-" "$args[@]" "$expl[@]" -d remdispd \
diff --git a/README b/README
index 2cf2266..fd4c59e 100644
--- a/README
+++ b/README
@@ -32,9 +32,17 @@ Zsh is a shell with lots of features.  For a list of some of these, see the
 file FEATURES, and for the latest changes see NEWS.  For more
 details, see the documentation.
 
-Incompatibilities since 5.4.2
+Incompatibilities since 5.5.1
 -----------------------------
 
+The completion helper _remote_files, typically used after a hostname
+with scp-style completion, now uses remote-files instead of files as a
+tag.  This makes it easier to restrict completions with the tag-order
+style.
+
+Incompatibilities between 5.4.2 and 5.5.1
+-----------------------------------------
+
 1) The default build-time maximum nested function depth has been
 decreased from 1000 to 500 based on user experience.  However,
 it can now be changed at run time via the variable FUNCNEST.

Re: scp completion options

[David Woodfall]

On Thursday 28 June 2018 17:31,
Bart Schaefer <schaefer@brasslantern.com> put forth the proposition:
> On Thu, Jun 28, 2018 at 1:56 PM, David Woodfall <dave@dawoodfall.net> wrote:
> >
> > Things I've tested so far:
> >
> > [...]
>
> _remote_files is most likely running
>   ssh -o BatchMode=yes -a -x $host ls -d1FL --
> where $host is obviously the remote name.  Try running that directly
> from your command line and see what you get.
>
> Try again replacing "ls" with /bin/ls just in case an alias is somehow
> being invoked, or find out if you have some other "ls" in the default
> search path.

Well I had another look at the problem of those escape characters
today and think that I've found the problem. I made a ssh function
some time ago that would change my screen title to user@host:

ssh() {
  print -n "\ek${*##* }\e\\"
  /usr/bin/ssh $@ 
  print -n \\ek${${(%)SCREEN//screen-*/%~}#\~/}\\e\\\\
}

I didn't realize that scp would also run the ssh binary. I assumed that its
autocomplete stuff was some build-in code.

To get around this I renamed the ssh function to mmmssh and then created

alias ssh='mmmssh'

Aliases are only available in an interactive shell.

Pretty daft way to get a user@host but it works. There's probably a more sane
way to do this.

Thanks for all the help and clues where to look.

-Dave

--

Besides, its really not worthwhile to use more than two times your physical
ram in swap (except in a select few situations). The performance of the system
becomes so abysmal you'd rather heat pins under your toenails while reciting
Windows95 source code and staring at porn flicks of Bob Dole than actually try
to type something.
  -- seen on c.o.l.development.system, about the size of the swap space

                                                            .--.  oo
                                                           (____)//
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~'