zsh-workers
 help / color / Atom feed
* PATCH: sshfs user-side automount
       [not found] <CGME20200217154528eucas1p17c3730dd3979ce40eb383d7f6889c5e2@eucas1p1.samsung.com>
@ 2020-02-17 15:45 ` Peter Stephenson
  2020-02-18 10:44   ` Daniel Shahaf
  0 siblings, 1 reply; 9+ messages in thread
From: Peter Stephenson @ 2020-02-17 15:45 UTC (permalink / raw)
  To: Zsh Hackers' List

Hi,

This certainly won't go in until the dust has settled, both on the
release and the proposed change, but I'd quite like to add some
user-side automount capability, in particular for the cdr system that I
use quite a lot (though you can slot it in anywhere, including your own
function front-end to cd).

The point is, in case it's not obvious:  I use sshfs quite a lot for
access to remote files these days, and as it's all done in user space
there's no automatic way of getting an ssh directory mounted.  This is
only really useful if you have seamless sshfs mounting, i.e. an ssh
agent in the background.

Obviously, please let me know whatever you don't like about it.  It'll
probably grow, at least for my own purposes.

It's documented as a style for cdr, which is how it's currently exposed,
but if it goes in, chpwd_check_mount probably needs a separate entry in
that section.

The syntax is currently a bit of a mouthful, but it's hard to make it
neater without also reducing flexibility.

pws


commit 6b1b417fb0da581f8186fbfaadfe8a8b07dc2b8c
Author: Peter Stephenson <p.stephenson@samsung.com>
Date:   Mon Feb 17 15:16:29 2020 +0000

    Not yet posted: Add chpwd_check_mount to handle automatic sshfs mounting.
    
    Use this in cdr.

diff --git a/Doc/Zsh/contrib.yo b/Doc/Zsh/contrib.yo
index c6bf745b7..252487fbb 100644
--- a/Doc/Zsh/contrib.yo
+++ b/Doc/Zsh/contrib.yo
@@ -386,6 +386,7 @@ findex(_cdr)
 findex(chpwd_recent_add)
 findex(chpwd_recent_dirs)
 findex(chpwd_recent_filehandler)
+findex(chpwd_check_mount)
 sect(Remembering Recent Directories)
 
 The function tt(cdr) allows you to change the working directory to a
@@ -615,6 +616,39 @@ directory stack is completely separate from the list of files saved
 by the mechanism used in this file there is no obvious reason to do
 this.
 )
+item(tt(mount-path))(
+This style takes pairs of arguments.  Each pair consists of a local
+directory path var(local-path), and a remote path for the form
+var(method):var(mount-spec).  If a directory to which tt(cdr) needs
+to change does not exit, the list of var(local-path)s is checked
+to see if one of them is a prefix of the target directory.
+If one is found, the remote path is used to provide the directory.
+
+Currently the only var(method) handled is tt(sshfs), for which
+var(mount-spec) should be a standard sshfs remote directory reference,
+so var(mount-spec) may be e.g. tt(user@remotehost:/path/to/dir).
+This causes tt(sshfs) to be invoked with the option
+tt(workaround=rename); this is likely to become configurable in future.
+This is most useful when there is an ssh agent running in the
+background, so that the mount action is invisible to the user.
+
+The source path is not rendered canonical (symbolic links are not
+removed), so it may be necessary to have multiple local directories
+with the same remote path.  For this purpose, the local directory
+path may take the form var(check-directory):var(mount-point).
+For example, var(check-directory) may be tt(/home/mydir/doc),
+a symbolic link to a directory under the var(mount-point)
+tt(/home/mydir/mnt/remote).
+
+Note that recursive mounting is also not currently handled, so
+the var(local-path) directories should not be subdirectories of one
+another.
+
+This style is provided by the function tt(chpwd_check_mount), which
+can be run separately.  It takes a single argument, the path
+to check.  This does not have to be a directory as prefixes
+are examined.
+)
 enditem()
 
 subsect(Use with dynamic directory naming)
diff --git a/Functions/Chpwd/cdr b/Functions/Chpwd/cdr
index 4bed88b13..7fc4345f6 100644
--- a/Functions/Chpwd/cdr
+++ b/Functions/Chpwd/cdr
@@ -268,6 +268,8 @@ else
     1=1
   elif [[ $# -ne 1 || $1 != <-> ]]; then
     if zstyle -t ':chpwd:' recent-dirs-default; then
+      # See below.
+      (( $# == 1 )) && chpwd_check_mount $1
       cd "$@"
       return
     else
@@ -329,6 +331,12 @@ if (( $1 > ${#reply} )); then
 fi
 dir=${reply[$1]}
 
+# This checks if the directory is available or can be mounted,
+# and returns failure if not, but we'll simply pass back the
+# (in context, more obvious) failure from pushd or cd.
+autoload -Uz chpwd_check_mount
+chwpd_check_mount $dir
+
 if zstyle -t ':chpwd:' recent-dirs-pushd; then
   pushd -- $dir
 else
diff --git a/Functions/Chpwd/chpwd_check_mount b/Functions/Chpwd/chpwd_check_mount
new file mode 100644
index 000000000..adc0bc65f
--- /dev/null
+++ b/Functions/Chpwd/chpwd_check_mount
@@ -0,0 +1,107 @@
+# This function is designed to do a poor person's automount in
+# the user space, typically of a sshfs file system as this is
+# entirely controlled by the user.
+#
+# Return 0 if the path is available, possibly after mounting, 1 if
+# it is still not available at the end of the function.
+#
+# The style mount-path in context :chpwd: is set to an array of pairs of
+# paths and URL-style references looking like
+#
+# /local/dir method:path-to-dir
+#
+# If the argument to the function is a path that doesn't exist, the
+# system checks to see if the path is under /local/dir.  If, so the
+# other element of the pair is examined.  If "method" is a known method
+# for moutning the remote path path-to-dir the path, it is mounted and
+# the function returns success.
+#
+# Currently the only method knonwn is sshfs, in which case path-to-dir
+# is a standard ssh path e.g. "rhost:/home/mydir".  Mounting is done
+# simply: "sshfs -o workaround=rename path-to_dir /local/dir".  This
+# may become more configurable in future.  It is assumed the user
+# has an appropriate ssh agent running, else the call may prompt for
+# login info at an unexpected place.
+#
+# Does not currently handle (the unusual case of) recursive mounts,
+# i.e. /local/dir and /local/dir/under/that does not handle the second case.
+#
+# The return status is 0 if the path exists; 1 if it does not exist
+# (even if a mount was made in an attempt to provide it); 2 if some
+# condition other than a missing directory was found, in particular
+# bad zstyle configuration or an sshfs failure.
+
+emulate -L zsh
+setopt extendedglob cbases
+
+# Nothing to if path exists.
+#
+# We'll allow the path to be something other than a directory as we
+# are in any case going to check prefixes.
+if [[ -e $1 ]]; then
+  if [[ -d $1 ]]; then
+    # As this may be the mount point itself, we'll assume it
+    # should be non-empty, though we don't know for sure.
+    local -a files
+    files=($1/*(DN))
+    (( ${#files} )) && return 0
+  else
+    # Not a directory, so assume everything is OK.
+    return 0
+  fi
+fi
+
+local -a match mbegin mend
+local dir
+if [[ $1 = /* ]]; then
+  dir="$1"
+else
+  # Hmm... We can't use (:a) or (:A) as the path doesn't yet exist in
+  # the file system.  We'll just bang it on the end of $PWD..
+  # It's not clear whether we should remove symbolic links from
+  # $PWD as we don't know whether the user has or has not rationalised
+  # the zstyle accordingly.
+  dir="$PWD/$1"
+  # Rationalise ..'s --- a bit naive, but hopefully good enough...
+  while [[ $dir = (#b)(*/)([^/]##)/..(/*|) ]]; do
+    dir="$match[1]${match[3]##/}"
+  done
+  dir=${dir%%/#}
+fi
+
+local -a mpath
+# If no directories we could mount, fail silently
+zstyle -a ':chpwd:' mount-path mpath || return 1
+
+local locdir remote mpoint
+
+for locdir remote in $mpath; do
+  # To be clever here we would look for the shortest matching path
+  # and work our way down.
+  if [[ $dir = ${locdir%%:*}(|/*) ]]; then
+    mpoint=${locdir#*:}
+    case $remote in
+      ((#b)sshfs:(*))
+      if ! sshfs -o workaround=rename $match[1] $mpoint; then
+        # Bad mount: it probably complained, but let's be clear.
+	print "$0: attempt to mount $remote for $locdir failed." >&2
+	return 2
+      fi
+      # Success / failure depending on whether path is now provided.
+      # To be clever (see above) could loop further.
+      [[ -e $dir ]]
+      ;;
+
+      (*)
+      # Incorrect configuration, so return noisily.
+      print "$0: method ${remote%%:*} not handled" >&2
+      return 2
+      ;;
+    esac
+  fi
+done
+
+# Final test in case we found something that might be a mount point.
+# If we couldn't mount it but this is the directory being referred to,
+# assume it's OK.
+[[ -e $dir ]]


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: PATCH: sshfs user-side automount
  2020-02-17 15:45 ` PATCH: sshfs user-side automount Peter Stephenson
@ 2020-02-18 10:44   ` Daniel Shahaf
  2020-02-18 11:10     ` Peter Stephenson
  0 siblings, 1 reply; 9+ messages in thread
From: Daniel Shahaf @ 2020-02-18 10:44 UTC (permalink / raw)
  To: Zsh Hackers' List

Peter Stephenson wrote on Mon, 17 Feb 2020 15:45 +0000:
> This certainly won't go in until the dust has settled, both on the
> release and the proposed change,

Why don't you push it to the 5.9 branch, then?  That's what it's for.

> +++ b/Doc/Zsh/contrib.yo
> @@ -386,6 +386,7 @@ findex(_cdr)
>  findex(chpwd_recent_add)

(The character on the first column is a non-breaking space, so
the diff couldn't easily be applied.)

> --- /dev/null
> +++ b/Functions/Chpwd/chpwd_check_mount
> @@ -0,0 +1,107 @@
> +# Return 0 if the path is available, possibly after mounting, 1 if
> +# it is still not available at the end of the function.
> +# The return status is 0 if the path exists; 1 if it does not exist
> +# (even if a mount was made in an attempt to provide it); 2 if some
> +# condition other than a missing directory was found, in particular
> +# bad zstyle configuration or an sshfs failure.

The return status is documented in two different places.

> +# If the argument to the function is a path that doesn't exist, the
> +# system checks to see if the path is under /local/dir.  If, so the
> +# other element of the pair is examined.  If "method" is a known method
> +# for moutning the remote path path-to-dir the path, it is mounted and

Typo "moutning"

> +
> +# We'll allow the path to be something other than a directory as we
> +# are in any case going to check prefixes.
> +if [[ -e $1 ]]; then
> +  if [[ -d $1 ]]; then

This does two stat()s in a row on what might be a subdirectory of an
sshfs mount.  If optimization is a concern, there might be a speed gain
from rearranging the code to «if [[ -d $1 ]]; … elif [[ -e $1 ]]; … fi»,
or possibly even to use zstat here.

> +    # As this may be the mount point itself, we'll assume it
> +    # should be non-empty, though we don't know for sure.
> +    local -a files
> +    files=($1/*(DN))
> +    (( ${#files} )) && return 0

Suggest to add the «Y1» glob qualifier, or to use the «F» glob qualifier.

Suggest to directly check whether $1 is a mountpoint.  On my system
there's a mountpoint(1) utility that can be used as «if mountpoint -q
/home; then», but it might be unportable.  For portability I guess we
could use «zstat +device».

> +  else
> +    # Not a directory, so assume everything is OK.
> +    return 0
> +  fi
> +fi

> +for locdir remote in $mpath; do
> +  # To be clever here we would look for the shortest matching path
> +  # and work our way down.
> +  if [[ $dir = ${locdir%%:*}(|/*) ]]; then
> +    mpoint=${locdir#*:}
> +    case $remote in
> +      ((#b)sshfs:(*))
> +      if ! sshfs -o workaround=rename $match[1] $mpoint; then

Quote $match[1] to prevent null elision.

Cheers,

Daniel

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: PATCH: sshfs user-side automount
  2020-02-18 10:44   ` Daniel Shahaf
@ 2020-02-18 11:10     ` Peter Stephenson
  2020-02-18 11:24       ` Daniel Shahaf
  2020-03-16 10:11       ` Peter Stephenson
  0 siblings, 2 replies; 9+ messages in thread
From: Peter Stephenson @ 2020-02-18 11:10 UTC (permalink / raw)
  To: zsh-workers

On Tue, 2020-02-18 at 10:44 +0000, Daniel Shahaf wrote:
> Peter Stephenson wrote on Mon, 17 Feb 2020 15:45 +0000:
> > 
> > This certainly won't go in until the dust has settled, both on the
> > release and the proposed change,
> Why don't you push it to the 5.9 branch, then?  That's what it's for.

As I understand it, the 5.9 branch is for finished changes;
there won't be any rationalisation when it's rebased into master,
so there's no more point pushing work in progress there than to
any other public branch, or have I missed the point?

Thanks for the other notes, I'll feed them into some further
tweaks.

pws


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: PATCH: sshfs user-side automount
  2020-02-18 11:10     ` Peter Stephenson
@ 2020-02-18 11:24       ` Daniel Shahaf
  2020-03-16 10:11       ` Peter Stephenson
  1 sibling, 0 replies; 9+ messages in thread
From: Daniel Shahaf @ 2020-02-18 11:24 UTC (permalink / raw)
  To: Peter Stephenson; +Cc: zsh-workers

Peter Stephenson wrote on Tue, 18 Feb 2020 11:10 +0000:
> On Tue, 2020-02-18 at 10:44 +0000, Daniel Shahaf wrote:
> > Peter Stephenson wrote on Mon, 17 Feb 2020 15:45 +0000:  
> > > 
> > > This certainly won't go in until the dust has settled, both on the
> > > release and the proposed change,  
> > Why don't you push it to the 5.9 branch, then?  That's what it's for.  
> 
> As I understand it, the 5.9 branch is for finished changes;
> there won't be any rationalisation when it's rebased into master,
> so there's no more point pushing work in progress there than to
> any other public branch, or have I missed the point?

I think you haven't: the 5.9 branch is for changes that would be
suitable for master if master weren't in soft freeze due to being in
the wake of a major release.

> Thanks for the other notes, I'll feed them into some further
> tweaks.

You're welcome.

Daniel

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: PATCH: sshfs user-side automount
  2020-02-18 11:10     ` Peter Stephenson
  2020-02-18 11:24       ` Daniel Shahaf
@ 2020-03-16 10:11       ` Peter Stephenson
  2020-03-16 18:36         ` Daniel Shahaf
  1 sibling, 1 reply; 9+ messages in thread
From: Peter Stephenson @ 2020-03-16 10:11 UTC (permalink / raw)
  To: zsh-workers

Here's an updated version I intend to commit if there are not further comments.

I've taken on board most of Daniel's comments, thanks.

(Lines are marked as "preformatted" in Evolution --- I hope that removes
hard spaces.)

pws

commit e8e950151b501011d0041c1955a55e151c564fde
Author: Peter Stephenson <p.stephenson@samsung.com>
Date:   Mon Feb 17 15:16:29 2020 +0000

    Not yet posted: Add chpwd_check_mount to handle automatic sshfs mounting.
    
    Use this in cdr.

diff --git a/Doc/Zsh/contrib.yo b/Doc/Zsh/contrib.yo
index 0909cd4f5..55285657a 100644
--- a/Doc/Zsh/contrib.yo
+++ b/Doc/Zsh/contrib.yo
@@ -386,6 +386,7 @@ findex(_cdr)
 findex(chpwd_recent_add)
 findex(chpwd_recent_dirs)
 findex(chpwd_recent_filehandler)
+findex(chpwd_check_mount)
 sect(Remembering Recent Directories)
 
 The function tt(cdr) allows you to change the working directory to a
@@ -615,8 +616,77 @@ directory stack is completely separate from the list of files saved
 by the mechanism used in this file there is no obvious reason to do
 this.
 )
+item(tt(mount-path))(
+This style is provided by the function tt(chpwd_check_mount), which
+is documented below in the subsection `Automatic sshfs mounting'.  This
+allows user-side automounting of directories provide by tt(sshfs).
+tt(cdr) already calls this function, so setting the style is
+sufficient to enable this behaviour.
+)
 enditem()
 
+subsect(Automatic sshfs mounting)
+
+The function tt(chpwd_check_mount) is provided to allow user-side
+automounting of directories by the tt(sshfs) command, a widely used
+utility that can provide a user with no system privileges direct file
+access to files visible via an tt(ssh) connection.
+
+The function takes a single argument, the path to check.  This does not
+have to be a directory as prefixes are examined.
+
+This function is called by tt(cdr) so that this ability is provided
+seamlessly in this case.  However, the function may also be called
+directly, for example in a user's function front-end to the tt(cd)
+builtin.
+
+To enable this feature, the tt(mount-path) style should be set in the
+tt(:chpwd:) context.  The style takes pairs of arguments.  Each pair
+consists of a local directory path var(local-path), and a remote path
+for the form var(method):var(mount-spec).  If a directory to which
+tt(cdr) needs to change does not exit, the list of var(local-path)s is
+checked to see if one of them is a prefix of the target directory.
+If one is found, the remote path is used to provide the directory.
+
+Currently the only var(method) handled is tt(sshfs), for which
+var(mount-spec) should be a standard sshfs remote directory reference,
+so var(mount-spec) may be e.g. tt(user@remotehost:/path/to/dir).
+By default this causes tt(sshfs) to be invoked with the option
+tt(workaround=rename); to change this, set the style tt(command-args)
+in the context `tt(:chpwd:sshfs:)'.  The value should be an
+array of command arguments preceding the remote directory and mount
+point starting with the command itself, typically `tt(sshfs)', so
+the default behaviour is equivalent to the following value:
+example(zstyle ':chwpd:sshfs:' command-path sshfs -o workaround=rename)
+
+This is most useful when there is an ssh agent running in the
+background, so that the mount action is invisible to the user.
+See the manual page for manref(ssh-agent)(1) if you are unfamiliar with
+this.
+
+The source path is not rendered canonical (symbolic links are not
+removed), so it may be necessary to have multiple local directories
+with the same remote path.  For this purpose, the local directory
+path may take the form var(check-directory):var(mount-point).
+For example, var(check-directory) may be tt(/home/mydir/doc),
+a symbolic link to a directory under the var(mount-point)
+tt(/home/mydir/mnt/remhost).
+
+Note that recursive mounting is also not currently handled, so
+the var(local-path) directories should not be subdirectories of one
+another.
+
+Here is a full style definition using the example above.  If
+tt(cdr) attempts to switch to a non-existent directory below
+tt(/home/mydir/doc) (or to tt(/home/mydir/doc) itself, if that exists
+but is empy), an attempt will be made to mount files from
+tt(myuser@remhost:/home/myuser) via tt(sshfs) at the mount point
+tt(/home/mydir/mnt/remhost).  The resulting tt(cd) succeeds if the
+originally requested directory is made available by this means.
+example(zstyle :chpwd: mount-point \
+  /home/mydir/doc:/home/mydir/mnt/remhost \
+  sshfs:myuser@remhost:/home/myuser)
+
 subsect(Use with dynamic directory naming)
 
 It is possible to refer to recent directories using the dynamic directory
diff --git a/Functions/Chpwd/cdr b/Functions/Chpwd/cdr
index 4bed88b13..d1818cd7d 100644
--- a/Functions/Chpwd/cdr
+++ b/Functions/Chpwd/cdr
@@ -268,6 +268,11 @@ else
     1=1
   elif [[ $# -ne 1 || $1 != <-> ]]; then
     if zstyle -t ':chpwd:' recent-dirs-default; then
+      if (( $# == 1 )); then
+	# See below.
+	autoload -Uz chpwd_check_mount
+	chpwd_check_mount $1
+      fi
       cd "$@"
       return
     else
@@ -329,6 +334,12 @@ if (( $1 > ${#reply} )); then
 fi
 dir=${reply[$1]}
 
+# This checks if the directory is available or can be mounted,
+# and returns failure if not, but we'll simply pass back the
+# (in context, more obvious) failure from pushd or cd.
+autoload -Uz chpwd_check_mount
+chpwd_check_mount $dir
+
 if zstyle -t ':chpwd:' recent-dirs-pushd; then
   pushd -- $dir
 else
diff --git a/Functions/Chpwd/chpwd_check_mount b/Functions/Chpwd/chpwd_check_mount
new file mode 100644
index 000000000..371fa181a
--- /dev/null
+++ b/Functions/Chpwd/chpwd_check_mount
@@ -0,0 +1,107 @@
+# This function is designed to do a poor person's automount in
+# the user space, typically of a sshfs file system as this is
+# entirely controlled by the user.
+#
+# The return status is 0 if the path exists; 1 if it does not exist
+# (even if a mount was made in an attempt to provide it); 2 if some
+# condition other than a missing directory was found, in particular
+# bad zstyle configuration or an sshfs failure.
+#
+# The style mount-path in context :chpwd: is set to an array of pairs of
+# paths and URL-style references looking like
+#
+# /local/dir method:path-to-dir
+#
+# If the argument to the function is a path that doesn't exist, the
+# system checks to see if the path is under /local/dir.  If, so the
+# other element of the pair is examined.  If "method" is a known method
+# for mounting the remote path path-to-dir the path, it is mounted and
+# the function returns success.
+#
+# Currently the only method knonwn is sshfs, in which case path-to-dir
+# is a standard ssh path e.g. "rhost:/home/mydir".  Mounting is done
+# simply: "sshfs -o workaround=rename path-to_dir /local/dir".  This
+# may become more configurable in future.  It is assumed the user
+# has an appropriate ssh agent running, else the call may prompt for
+# login info at an unexpected place.
+#
+# Does not currently handle (the unusual case of) recursive mounts,
+# i.e. /local/dir and /local/dir/under/that does not handle the second case.
+
+emulate -L zsh
+setopt extendedglob cbases
+
+local -a mpath
+# If no directories we could mount, fail silently;
+# no point even looking at the argument.
+zstyle -a ':chpwd:' mount-path mpath || return 1
+
+# Nothing to if path exists.
+#
+# We'll allow the path to be something other than a directory as we
+# are in any case going to check prefixes.
+if [[ -d $1 ]]; then
+  # As this may be the mount point itself, we'll assume it
+  # should be non-empty, though we don't know for sure.
+  local -a files
+  # Glob dots; expand to empty if no matches; don't bother globbing
+  # more than one file, we just want to know if there are any
+  files=($1/*(DNY1))
+  (( ${#files} )) && return 0
+elif [[ -e $1 ]]; then
+  # Not a directory, so assume everything is OK.
+  return 0
+fi
+
+local -a match mbegin mend
+local dir
+if [[ $1 = /* ]]; then
+  dir="$1"
+else
+  # Hmm... We can't use (:a) or (:A) as the path doesn't yet exist in
+  # the file system.  We'll just bang it on the end of $PWD..
+  # It's not clear whether we should remove symbolic links from
+  # $PWD as we don't know whether the user has or has not rationalised
+  # the zstyle accordingly.
+  dir="$PWD/$1"
+  # Rationalise ..'s --- a bit naive, but hopefully good enough...
+  while [[ $dir = (#b)(*/)([^/]##)/..(/*|) ]]; do
+    dir="$match[1]${match[3]##/}"
+  done
+  dir=${dir%%/#}
+fi
+
+local locdir remote mpoint cmdargs
+
+for locdir remote in $mpath; do
+  # To be clever here we would look for the shortest matching path
+  # and work our way down.
+  if [[ $dir = ${locdir%%:*}(|/*) ]]; then
+    mpoint=${locdir#*:}
+    case $remote in
+      ((#b)sshfs:(*))
+      zstyle -a ':chpwd:sshfs:' command-args cmdargs ||
+	  cmdargs=(sshfs -o workaround=rename)
+      if ! "${cmdargs[@]}" "${match[1]}" "$mpoint"; then
+        # Bad mount: it probably complained, but let's be clear.
+	print -r -- "$0: attempt to mount $remote for $locdir failed." >&2
+	return 2
+      fi
+      # Break for success / failure depending on whether path is now provided.
+      # To be clever (see above) could loop further.
+      break
+      ;;
+
+      (*)
+      # Incorrect configuration, so return noisily.
+      print -r -- "$0: method ${remote%%:*} not handled" >&2
+      return 2
+      ;;
+    esac
+  fi
+done
+
+# Final test in case we found something that might be a mount point.
+# If we couldn't mount it but this is the directory being referred to,
+# assume it's OK.
+[[ -e $dir ]]


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: PATCH: sshfs user-side automount
  2020-03-16 10:11       ` Peter Stephenson
@ 2020-03-16 18:36         ` Daniel Shahaf
  2020-03-17 12:19           ` Peter Stephenson
  0 siblings, 1 reply; 9+ messages in thread
From: Daniel Shahaf @ 2020-03-16 18:36 UTC (permalink / raw)
  To: Peter Stephenson; +Cc: zsh-workers

Peter Stephenson wrote on Mon, 16 Mar 2020 10:11 +0000:
> (Lines are marked as "preformatted" in Evolution --- I hope that removes
> hard spaces.)

That seems to have made no difference.

You might find it easier to run «git format-patch -1» and then attach
the resulting file.

> +the default behaviour is equivalent to the following value:
> +example(zstyle ':chwpd:sshfs:' command-path sshfs -o workaround=rename)

According to the sshfs(1) man page, the "buflimit" workaround is
enabled by default.

Is the "buflimit" workaround enabled when sshfs(1) is invoked as «sshfs
-o workaround=rename»?  I.e., does defaulting the "rename" workaround
enabled effectively change sshfs(1)'s default behaviour?

Cheers,

Daniel

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: PATCH: sshfs user-side automount
  2020-03-16 18:36         ` Daniel Shahaf
@ 2020-03-17 12:19           ` Peter Stephenson
  2020-03-17 14:00             ` Daniel Shahaf
  0 siblings, 1 reply; 9+ messages in thread
From: Peter Stephenson @ 2020-03-17 12:19 UTC (permalink / raw)
  To: Zsh Hackers' List

On Mon, 2020-03-16 at 18:36 +0000, Daniel Shahaf wrote:
> Peter Stephenson wrote on Mon, 16 Mar 2020 10:11 +0000:
> > 
> > (Lines are marked as "preformatted" in Evolution --- I hope that removes
> > hard spaces.)
> That seems to have made no difference.
> 
> You might find it easier to run «git format-patch -1» and then attach
> the resulting file.

I can certainly do that but I'm not sure quite when this is turning
up --- may be because I have an older version of Evolution here.

> > 
> > +the default behaviour is equivalent to the following value:
> > +example(zstyle ':chwpd:sshfs:' command-path sshfs -o workaround=rename)
> According to the sshfs(1) man page, the "buflimit" workaround is
> enabled by default.
> 
> Is the "buflimit" workaround enabled when sshfs(1) is invoked as «sshfs
> -o workaround=rename»?  I.e., does defaulting the "rename" workaround
> enabled effectively change sshfs(1)'s default behaviour?

My reading of the manual page is you'd need to set "nobuflimit" explicitly
to turn it off, else there wouldn't be much use for the "no" prefix,
you'd always have to list the ones you want to turn on.  So I think
the way it's done is there to fix this exact issue.

pws


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: PATCH: sshfs user-side automount
  2020-03-17 12:19           ` Peter Stephenson
@ 2020-03-17 14:00             ` Daniel Shahaf
  2020-03-17 14:08               ` Peter Stephenson
  0 siblings, 1 reply; 9+ messages in thread
From: Daniel Shahaf @ 2020-03-17 14:00 UTC (permalink / raw)
  To: Peter Stephenson; +Cc: Zsh Hackers' List

Peter Stephenson wrote on Tue, 17 Mar 2020 12:19 +0000:
> On Mon, 2020-03-16 at 18:36 +0000, Daniel Shahaf wrote:
> > Peter Stephenson wrote on Mon, 16 Mar 2020 10:11 +0000:  
> > > 
> > > (Lines are marked as "preformatted" in Evolution --- I hope that removes
> > > hard spaces.)  
> > That seems to have made no difference.
> > 
> > You might find it easier to run «git format-patch -1» and then attach
> > the resulting file.  
> 
> I can certainly do that but I'm not sure quite when this is turning
> up --- may be because I have an older version of Evolution here.
> 

Yeah, the MUA would be my first suspect.

You can set «git config --global format.suffix .patch.txt» to get a .txt extension.

> > > 
> > > +the default behaviour is equivalent to the following value:
> > > +example(zstyle ':chwpd:sshfs:' command-path sshfs -o workaround=rename)  
> > According to the sshfs(1) man page, the "buflimit" workaround is
> > enabled by default.
> > 
> > Is the "buflimit" workaround enabled when sshfs(1) is invoked as «sshfs
> > -o workaround=rename»?  I.e., does defaulting the "rename" workaround
> > enabled effectively change sshfs(1)'s default behaviour?  
> 
> My reading of the manual page is you'd need to set "nobuflimit" explicitly
> to turn it off, else there wouldn't be much use for the "no" prefix,
> you'd always have to list the ones you want to turn on.  So I think
> the way it's done is there to fix this exact issue.

In the alternative semantics, the "no" prefix wouldn't be useless; it'd still
be useful to allow people to write scripts such as «f() { sshfs -o
workaround=foo "$@" }» that may be invoked as «f -o workaround=nofoo» to
disable foo.  However, I agree it's probably implemented as you say.

I don't see anything about this in the output of `sshfs -o sshfs_debug -o debug
-o workaround=rename`.

Cheers,

Daniel

P.S. Speaking of sshfs_debug, here's a quick updated completion.  Some
of the completed values aren't documented in the man page on my system,
but I left them in, as I'm not sure whether they were removed before or
added after the version I have installed.

8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
From 19bc7ded6f1752c8a4283f262310730059d33f04 Mon Sep 17 00:00:00 2001
From: Daniel Shahaf <danielsh@apache.org>
Date: Tue, 17 Mar 2020 13:35:48 +0000
Subject: [PATCH] _sshfs: Complete some more options

---
 Completion/Linux/Command/_sshfs | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/Completion/Linux/Command/_sshfs b/Completion/Linux/Command/_sshfs
index 3363ecdc0..66faf9997 100644
--- a/Completion/Linux/Command/_sshfs
+++ b/Completion/Linux/Command/_sshfs
@@ -19,8 +19,14 @@ _arguments -C -S : \
   ':mountpoint:_files -/' && ret=0
 
 if [[ $state == options ]]; then
-  _values -s , "sshfs or fuse or mount options" \
+  # TODO complete ssh(1) options
+  _values -s , "options to ssh, sshfs, mount, or FUSE" \
+    'port:number' \
+    'compression: :(yes no)' \
     reconnect delay_connect sshfs_sync no_readahead sync_readdir \
+    sshfs_debug \
+    'cache: :(yes no)' \
+    'cache_timeout:timeout (seconds)' \
     'dir_cache:cache setting:(yes no)' \
     'dcache_max_size:size [10000]' \
     'dcache_timeout:timeout (seconds) [20]' \
@@ -37,12 +43,13 @@ if [[ $state == options ]]; then
     sftp_server:path:_files \
     directport:port:_ports \
     slave disable_hardlink transform_symlinks follow_symlinks no_check_root password_stdin \
+    debug \
     allow_other allow_root auto_unmount nonempty default_permissions \
     fsname:filesystem\ name \
     subtype:filesystem\ type \
     large_read \
     max_read:max\ size \
-    hard_remove use_ino readdir_ino direct_io kernel_cache auto_cache \
+    hard_remove use_ino readdir_ino direct_io kernel_cache auto_cache noauto_cache \
     'umask:permissions' \
     'uid:owner' 'gid:group' \
     'entry_timeout:timeout (seconds) [1]' \
@@ -60,7 +67,7 @@ if [[ $state == options ]]; then
     congestion_threshold:threshold \
     async_read sync_read atomic_o_trunc big_writes no_remote_lock no_remote_flock \
     no_remote_posix_lock splice_write splice_move splice_read \
-    from_code:charset to_code:charset subdir:_directories rellinks && ret=0
+    from_code:charset to_code:charset subdir:_directories rellinks norellinks && ret=0
 fi
 
 return ret


> 
> pws
> 


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: PATCH: sshfs user-side automount
  2020-03-17 14:00             ` Daniel Shahaf
@ 2020-03-17 14:08               ` Peter Stephenson
  0 siblings, 0 replies; 9+ messages in thread
From: Peter Stephenson @ 2020-03-17 14:08 UTC (permalink / raw)
  To: Zsh Hackers' List

On Tue, 2020-03-17 at 14:00 +0000, Daniel Shahaf wrote:
> > > Is the "buflimit" workaround enabled when sshfs(1) is invoked as «sshfs
> > > -o workaround=rename»?  I.e., does defaulting the "rename" workaround
> > > enabled effectively change sshfs(1)'s default behaviour?  
> > My reading of the manual page is you'd need to set "nobuflimit" explicitly
> > to turn it off, else there wouldn't be much use for the "no" prefix,
> > you'd always have to list the ones you want to turn on.  So I think
> > the way it's done is there to fix this exact issue.
> In the alternative semantics, the "no" prefix wouldn't be useless; it'd still
> be useful to allow people to write scripts such as «f() { sshfs -o
> workaround=foo "$@" }» that may be invoked as «f -o workaround=nofoo» to
> disable foo.  However, I agree it's probably implemented as you say.

Yeah, I think that's good enough for our due diligence.  The manual
entry added is explicit about the function's default behaviour and there
is a style you can set.

cheers
pws


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, back to index

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CGME20200217154528eucas1p17c3730dd3979ce40eb383d7f6889c5e2@eucas1p1.samsung.com>
2020-02-17 15:45 ` PATCH: sshfs user-side automount Peter Stephenson
2020-02-18 10:44   ` Daniel Shahaf
2020-02-18 11:10     ` Peter Stephenson
2020-02-18 11:24       ` Daniel Shahaf
2020-03-16 10:11       ` Peter Stephenson
2020-03-16 18:36         ` Daniel Shahaf
2020-03-17 12:19           ` Peter Stephenson
2020-03-17 14:00             ` Daniel Shahaf
2020-03-17 14:08               ` Peter Stephenson

zsh-workers

Archives are clonable: git clone --mirror http://inbox.vuxu.org/zsh-workers

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.workers


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git