Bug in remote use of notmuch

Bug in remote use of notmuch

[Mark Walters]

I am experimenting with using notmuch remotely over ssh (as in the
NEWS file; i.e. with a script containing ssh user@host notmuch "$@")
This is mostly excellent but it seems to get confused by some queries.
For example those containing brackets or just consisting of *. I think
this is a problem with ssh spawning a shell on the remote machine
which doesn't like the brackets or *.

Explicitly to reproduce the problem start notmuch with a remote
database using a script as above;
type * in the search box;
and emacs shows:
End of search results. (process returned 1)

If you search for "*" you get the expected results.

Mark

Re: Bug in remote use of notmuch

[Michal Sojka]

On Wed, 10 Nov 2010, Mark Walters wrote:
> I am experimenting with using notmuch remotely over ssh (as in the
> NEWS file; i.e. with a script containing ssh user@host notmuch "$@")
> This is mostly excellent but it seems to get confused by some queries.
> For example those containing brackets or just consisting of *. I think
> this is a problem with ssh spawning a shell on the remote machine
> which doesn't like the brackets or *.
> 
> Explicitly to reproduce the problem start notmuch with a remote
> database using a script as above;
> type * in the search box;
> and emacs shows:
> End of search results. (process returned 1)

Hi Mark,

you are right, that there are problems with the queries containing shell
meta characters. AFAIK the probelm is not caused by the remote shell, as
 notmuch is there invoked directly by ssh, but by the shell invoking the
ssh. I do not know precisely why, but the following script seems to work
correctly even for the queries containing shell meta characters. It uses
bash's printf extension to print shell-quoted version of a string.

  #!/bin/bash
  printf -v args "%q " "$@"
  ssh example.org notmuch $args

-Michal

Re: Bug in remote use of notmuch

[Austin Clements]

[-- Attachment #1: Type: text/plain, Size: 1732 bytes --]

Unfortunately, expansion *is* performed by the remote shell, which is why
your shell quoting approach works (and is necessary).  There's really no way
around this, since the ssh client simply joins all of its trailing arguments
with spaces and sends this single string to the ssh server, which exec()s
$SHELL -c <string>.
On Nov 18, 2010 4:09 PM, "Michal Sojka" <sojkam1@fel.cvut.cz> wrote:
> On Wed, 10 Nov 2010, Mark Walters wrote:
>> I am experimenting with using notmuch remotely over ssh (as in the
>> NEWS file; i.e. with a script containing ssh user@host notmuch "$@")
>> This is mostly excellent but it seems to get confused by some queries.
>> For example those containing brackets or just consisting of *. I think
>> this is a problem with ssh spawning a shell on the remote machine
>> which doesn't like the brackets or *.
>>
>> Explicitly to reproduce the problem start notmuch with a remote
>> database using a script as above;
>> type * in the search box;
>> and emacs shows:
>> End of search results. (process returned 1)
>
> Hi Mark,
>
> you are right, that there are problems with the queries containing shell
> meta characters. AFAIK the probelm is not caused by the remote shell, as
> notmuch is there invoked directly by ssh, but by the shell invoking the
> ssh. I do not know precisely why, but the following script seems to work
> correctly even for the queries containing shell meta characters. It uses
> bash's printf extension to print shell-quoted version of a string.
>
> #!/bin/bash
> printf -v args "%q " "$@"
> ssh example.org notmuch $args
>
> -Michal
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

[-- Attachment #2: Type: text/html, Size: 2380 bytes --]

Re: Bug in remote use of notmuch

[Michal Sojka]

On Fri, 19 Nov 2010, Austin Clements wrote:
> Unfortunately, expansion *is* performed by the remote shell, which is why
> your shell quoting approach works (and is necessary).  There's really no way
> around this, since the ssh client simply joins all of its trailing arguments
> with spaces and sends this single string to the ssh server, which exec()s
> $SHELL -c <string>.

Yes, your're right. I was confused by ssh(1) which says that server
executes either login shell or the command.

-M