bug#13299: 24.3.50; Tramp adb and device not found

bug#13299: 24.3.50; Tramp adb and device not found

[nyc4bos]

Hi,

When the ADB device drivers are not loaded Tramp keeps trying
to look for them until you ^G.

The "*tramp/adb nil*" buffer then contains:

* daemon not running. starting it now on port 5037 *
* daemon started successfully *
error: device not found

Can Tramp be made to print this out and/or otherwis exit gracefully?

Thanks.



In GNU Emacs 24.3.50.1 (i386-mingw-nt6.1.7601)
 of 2012-12-27 on MS-W7-DANI
Bzr revision: 111346 rgm@gnu.org-20121227111738-6kwixgc9fa2pxvbp
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -Ic:/emacs/libs/libXpm-3.5.10/include -Ic:/emacs/libs/libXpm-3.5.10/src
 -Ic:/emacs/libs/libpng-dev_1.4.3-1_win32/include
 -Ic:/emacs/libs/zlib-dev_1.2.5-2_win32/include
 -Ic:/emacs/libs/giflib-4.1.4-1-lib/include
 -Ic:/emacs/libs/jpeg-6b-4-lib/include
 -Ic:/emacs/libs/tiff-3.8.2-1-lib/include
 -Ic:/emacs/libs/libxml2-2.7.8-w32-bin/include/libxml2
 -Ic:/emacs/libs/gnutls-3.1.5-w32/include
 -Ic:/emacs/libs/libiconv-1.14-2-mingw32-dev/include'

Important settings:
  value of $LANG: en_US
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <menu-bar> 
<help-menu> <send-emacs-bug-report>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp w32-common-fns disp-table w32-win
w32-vars tool-bar dnd fontset image regexp-opt fringe tabulated-list
newcomment lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer button faces cus-face macroexp files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process w32notify w32
multi-tty emacs)

bug#13299: 24.3.50; Tramp adb and device not found

[Jürgen Hötzel]

> From: nyc4bos@aol.com
> To: 13299@debbugs.gnu.org
> Cc:
> Date: Fri, 28 Dec 2012 21:28:37 +0000
> Subject: bug#13299: 24.3.50; Tramp adb and device not found
> Hi,
>
> When the ADB device drivers are not loaded Tramp keeps trying
> to look for them until you ^G.
>
> The "*tramp/adb nil*" buffer then contains:
>
> * daemon not running. starting it now on port 5037 *
> * daemon started successfully *
> error: device not found
>
> Can Tramp be made to print this out and/or otherwis exit gracefully?
>

Fixed in Head: http://git.savannah.gnu.org/cgit/tramp.git/commit/?id=1697ee048d475ed29bb8074a67800c550b9b6759

Thanks for your report

Jürgen

bug#13299: 24.3.50; Tramp adb and device not found

[Michael Albinus]

Jürgen Hötzel <juergen@archlinux.org> writes:

> Fixed in Head:
> http://git.savannah.gnu.org/cgit/tramp.git/commit/?id=1697ee048d475ed29bb8074a67800c550b9b6759

Merged into Emacs trunk, rev#111389.

> Thanks for your report
>
> Jürgen

Best regards, Michael.

bug#13299: 24.3.50; Tramp adb and device not found

[nyc4bos]

Michael Albinus <michael.albinus@gmx.de> writes:

> Jürgen Hötzel <juergen@archlinux.org> writes:
>
>> Fixed in Head:
>> http://git.savannah.gnu.org/cgit/tramp.git/commit/?id=1697ee048d475ed29bb8074a67800c550b9b6759
>
> Merged into Emacs trunk, rev#111389.

Bzr 111389  fixed it, however it was subsequently broken again.

Not sure whether or not with either bzr 111425 or 111424 or some other
change since Bzr 111393 to the trunk.

Now with Bzr 111425 when doing:

  ^X^F/adb::/?

you see in the echo area:

Making completion list...

but nothing else happens and Emacs is locked up.

Not even ^G (keyboard-quit) or ^G^G^G unlocks Emacs.

You can only kill emacs from the command line prompt.

However, if adb is already started:

   adb fork-server server

then Emacs displays:

Making completion list...
Find file: /adb::/ [No completions]


Thanks.

>
>> Thanks for your report
>>
>> Jürgen
>
> Best regards, Michael.

bug#13299: 24.3.50; Tramp adb and device not found

[Jürgen Hötzel]

Could you please try:

(require 'tramp-adb)

before accessing the adb filename?

Thanks, Jürgen

bug#13299: 24.3.50; Tramp adb and device not found

[Michael Albinus]

nyc4bos@aol.com writes:

Hi,

> Now with Bzr 111425 when doing:
>
>   ^X^F/adb::/?
>
> you see in the echo area:
>
> Making completion list...
>
> but nothing else happens and Emacs is locked up.
>
> Not even ^G (keyboard-quit) or ^G^G^G unlocks Emacs.
>
> You can only kill emacs from the command line prompt.
>
> However, if adb is already started:
>
>    adb fork-server server
>
> then Emacs displays:
>
> Making completion list...
> Find file: /adb::/ [No completions]

Thare have been some very recent changes in tramp-adb.el, which should
improve handling of "/adb::". Bzr revision 111433. With that patch
level, I'm not able to reproduce the problem.

Could you, please, check?

> Thanks.

Best regards, Michael.

bug#13299: 24.3.50; Tramp adb and device not found

[nyc4bos]

Jürgen Hötzel <juergen@archlinux.org> writes:

> Could you please try:
>
> (require 'tramp-adb)
>
> before accessing the adb filename?

  Unfortunately, the same result (frozen emacs).
>
> Thanks, Jürgen

bug#13299: 24.3.50; Tramp adb and device not found

[nyc4bos]

Hi,

Michael Albinus <michael.albinus@gmx.de> writes:

> nyc4bos@aol.com writes:
>
> Hi,
>
>> Now with Bzr 111425 when doing:
>>
>>   ^X^F/adb::/?
>>
>> you see in the echo area:
>>
>> Making completion list...
>>
>> but nothing else happens and Emacs is locked up.
>>
>> Not even ^G (keyboard-quit) or ^G^G^G unlocks Emacs.
>>
>> You can only kill emacs from the command line prompt.
>>
>> However, if adb is already started:
>>
>>    adb fork-server server
>>
>> then Emacs displays:
>>
>> Making completion list...
>> Find file: /adb::/ [No completions]
>
> Thare have been some very recent changes in tramp-adb.el, which should
> improve handling of "/adb::". Bzr revision 111433. With that patch
> level, I'm not able to reproduce the problem.
>
> Could you, please, check?

Same result.

I then tried again, this time killing adb and the Emacs echo area then
showed:

Find file: /adb::/

However, after typing in ?, a new adb process was created and
Emacs showed in the echo area:

Making completion list...

and nothing else.

So it looks Emacs is waiting on adb (for some type of response perhap?)
which ^G (keyboard-quit) or ^G^G^G wont abort for Emacs.

I opened up a bug report for this (no response to ^G):

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13381

Once adb is killed outside of Emacs and the echo area now shows the
"Find file: /adb::/" prompt in place of:

Making completion list...

the *Message* buffer then contains:

Waiting for process to die...done


>
>> Thanks.
>
> Best regards, Michael.

bug#13299: 24.3.50; Tramp adb and device not found

[nyc4bos]

Michael Albinus <michael.albinus@gmx.de> writes:
Hi Michael,

> nyc4bos@aol.com writes:
>
> Hi,
>
>> Now with Bzr 111425 when doing:
>>
>>   ^X^F/adb::/?
>>
>> you see in the echo area:
>>
>> Making completion list...
>>
>> but nothing else happens and Emacs is locked up.
>>
>> Not even ^G (keyboard-quit) or ^G^G^G unlocks Emacs.
>>
>> You can only kill emacs from the command line prompt.
>>
>> However, if adb is already started:
>>
>>    adb fork-server server
>>
>> then Emacs displays:
>>
>> Making completion list...
>> Find file: /adb::/ [No completions]
>
> Thare have been some very recent changes in tramp-adb.el, which should
> improve handling of "/adb::". Bzr revision 111433. With that patch
> level, I'm not able to reproduce the problem.
>
> Could you, please, check?

Sill having the same problems with Bzr revision: 111604.

I have to kill adb from the command line in order to get Emacs to
respond.

Killing adb and then ^X^F/adb::/? a times finally gets Emacs to
list the files.  But a subsequent ^X^F/adb::/? gets back to the
same problem.

(Of course, eventually getting it to works only happens if the
drivers are loaded first.  Without the drivers, Emacs just locks up
until adb is killed -- ^G or ^G^G^G doesn't work). 
>
>> Thanks.
>
> Best regards, Michael.

bug#13299: 24.3.50; Tramp adb and device not found

[Michael Albinus]

nyc4bos@aol.com writes:

> Hi Michael,

Hi,

> Sill having the same problems with Bzr revision: 111604.
>
> I have to kill adb from the command line in order to get Emacs to
> respond.
>
> Killing adb and then ^X^F/adb::/? a times finally gets Emacs to
> list the files.  But a subsequent ^X^F/adb::/? gets back to the
> same problem.

It would be great, if you could set `tramp-verbose' to 6 first. The
resulting debug buffer could show us, where Tramp is hangigng.

> (Of course, eventually getting it to works only happens if the
> drivers are loaded first.  Without the drivers, Emacs just locks up
> until adb is killed -- ^G or ^G^G^G doesn't work).

Which "drivers" are you speaking about? Sorry, I'm not an experienced
ADK user.

Best regards, Michael.

bug#13299: 24.3.50; Tramp adb and device not found

[nyc4bos]

Michael Albinus <michael.albinus@gmx.de> writes:
Hi Michael,

> nyc4bos@aol.com writes:
>
>> Hi Michael,
>
> Hi,
>
>> Sill having the same problems with Bzr revision: 111604.
>>
>> I have to kill adb from the command line in order to get Emacs to
>> respond.
>>
>> Killing adb and then ^X^F/adb::/? a times finally gets Emacs to
>> list the files.  But a subsequent ^X^F/adb::/? gets back to the
>> same problem.
>
> It would be great, if you could set `tramp-verbose' to 6 first. The
> resulting debug buffer could show us, where Tramp is hangigng.

Here are the contents of the "*debug tramp/adb *" with `
`(setq tramp-verbose 6)' WITHOUT the Android device connected to
Windows:

;; GNU Emacs: 24.3.50.1 Tramp: 2.2.7-pre -*- mode: outline; -*-
18:03:45.471000 tramp-file-name-handler (1) # Interrupt received in operation (file-name-all-completions  /adb::/)

You don't see this until you type ^G (keyboard-quit) and kill the
adb process from outside of Emacs.  Until then, Emacs just shows in the
echo area:

            Making completion list...

and appears "frozen" with numerous ^G having no effect.

After killing adb (and then getting the above message in the
"*debug tramp/adb *"), you then see in the echo area:

Find file: ~//adb::/

Typing ? then creates a new adb process ("adb devices") which when
it completes, creates a "adb fork-server server" process.

Emacs again is "frozen" with "Making completion list...".

Typing ^G and then killing adb from outside of Emacs, then yields in
the "*debug tramp/adb *" buffer:

18:07:03.424000 tramp-file-name-handler (1) # Interrupt received in operation (file-name-all-completions  /adb::/)
18:07:03.425000 tramp-file-name-handler (1) # Interrupt received in
operation (file-name-completion  /adb::/ file-exists-p)

>
>> (Of course, eventually getting it to works only happens if the
>> drivers are loaded first.  Without the drivers, Emacs just locks up
>> until adb is killed -- ^G or ^G^G^G doesn't work).
>
> Which "drivers" are you speaking about? Sorry, I'm not an experienced
> ADK user.

These are the Android USB drivers.

Before any of my testing, I restore/roolback the system to the state
in which I am using the drivers that came with Windows.

>
> Best regards, Michael.

bug#13299: 24.3.50; Tramp adb and device not found

[Michael Albinus]

nyc4bos@aol.com writes:

> Hi Michael,

Hi,

> ;; GNU Emacs: 24.3.50.1 Tramp: 2.2.7-pre -*- mode: outline; -*-
> 18:03:45.471000 tramp-file-name-handler (1) # Interrupt received in
> operation (file-name-all-completions /adb::/)
>
> You don't see this until you type ^G (keyboard-quit) and kill the
> adb process from outside of Emacs.

I still have no chance to test under MS Windows. However, I have added
blindly a timeout of 10 seconds. Could you, please, check?

Best regards, Michael.

bug#13299: 24.3.50; Tramp adb and device not found

[nyc4bos]

Hi Michael,

Michael Albinus <michael.albinus@gmx.de> writes:

> nyc4bos@aol.com writes:
>
>> Hi Michael,
>
> Hi,
>
>> ;; GNU Emacs: 24.3.50.1 Tramp: 2.2.7-pre -*- mode: outline; -*-
>> 18:03:45.471000 tramp-file-name-handler (1) # Interrupt received in
>> operation (file-name-all-completions /adb::/)
>>
>> You don't see this until you type ^G (keyboard-quit) and kill the
>> adb process from outside of Emacs.
>
> I still have no chance to test under MS Windows. However, I have added
> blindly a timeout of 10 seconds. Could you, please, check?

With bzr 111935, it no longer hangs with:

     Making completion list...

It looks like it quickly flashing with:

      Find file: ~//adb::/ [No Completions]

and then displays:

      Find file: ~//adb::/


The *Messages* buffer has:

16:33:52.812000 tramp-adb-maybe-open-connection (1) # File error: No
device connected

So it looks like it now works as expected, since, indeed, the device was
not connected.

Thanks!

>
> Best regards, Michael.

bug#13299: 24.3.50; Tramp adb and device not found

[nyc4bos]

Hi Michael,

>> I still have no chance to test under MS Windows. However, I have added
>> blindly a timeout of 10 seconds. Could you, please, check?
>
> With bzr 111935, it no longer hangs with:

Looks like I spoke to fast.

It still hangs.

I suspect it occurs when `adb devices' returns the following:

* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached


Notice that it is blank and a device is not listed.

bug#13299: 24.3.50; Tramp adb and device not found

[Michael Albinus]

nyc4bos@aol.com writes:

> Hi Michael,

Hi,

> Looks like I spoke to fast.
>
> It still hangs.
>
> I suspect it occurs when `adb devices' returns the following:
>
> * daemon not running. starting it now on port 5037 *
> * daemon started successfully *
> List of devices attached
>
> Notice that it is blank and a device is not listed.

I can reproduce this message from a shell, if adb does not run on my
local machine, and no device is connected. But it doesn't harm Tramp,
and Emacs does not hang.

In order to reproduce your problem, I have killed adb on my local
machine prior to the following test runs.

1st test
========

C-x C-f /adb: <TAB>
  => "[Sole completion]"

2nd test
========

C-x C-f /adb:: <TAB>
  => "[No match]"

3rd test
========

C-x C-f /adb:: <RET>
  => "No device connected"

So I cannot reproduce the problem. As usual, my local machine does not
run MS Windows but Ubuntu; maybe this is the difference.

Could you, please, tell exactly which key sequence you have used? And
please use "emacs -Q" for your test.

I have used the following Emacs version for test:

GNU Emacs 24.3.50.20 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.13)
 of 2013-03-09 on detlef

Best regards, Michael.

bug#13299: 24.3.50; Tramp adb and device not found

[nyc4bos]

Michael Albinus <michael.albinus@gmx.de> writes:

> nyc4bos@aol.com writes:
>
>> Hi Michael,
>
> Hi,
>
>> Looks like I spoke to fast.
>>
>> It still hangs.
>>
>> I suspect it occurs when `adb devices' returns the following:
>>
>> * daemon not running. starting it now on port 5037 *
>> * daemon started successfully *
>> List of devices attached
>>
>> Notice that it is blank and a device is not listed.
>
> I can reproduce this message from a shell, if adb does not run on my
> local machine, and no device is connected. But it doesn't harm Tramp,
> and Emacs does not hang.
>
> In order to reproduce your problem, I have killed adb on my local
> machine prior to the following test runs.

Here are the results of my similiar tests.  All test are with
runemacs.exe -Q:

>
> 1st test
> ========
>
> C-x C-f /adb: <TAB>
>   => "[Sole completion]"

I get
  => "[No match]"

When I type
C-x C-d /adb:?
I then get (with ?, that is a question mark)
 => "[Sole completion]"

>
> 2nd test
> ========
>
> C-x C-f /adb:: <TAB>
>   => "[No match]"

This creates the `adb' process and hangs for me.

Hangs until externally kill `adb' process.  Then the *debug tramp/adb * buffer
contains:
15:33:18.141000 tramp-adb-get-ls-command (5) # Finding a suitable `ls' command
15:33:59.580000 tramp-adb-maybe-open-connection (1) # File error: No device connected
15:33:59.590000 tramp-adb-get-ls-command (5) # Finding a suitable `ls' command
15:34:12.370000 tramp-file-name-handler (1) # Interrupt received in operation (file-name-all-completions  /adb::/)

I have to kill the `adb' process a few times because it forks a new
`adb' process until I can see the *debug tramp/adb * buffer.


If I type `?' instead:

C-x C-f /adb::?

I get:

Making completion list...

and it hangs until I kill the `adb' process

15:53:15.449000 tramp-adb-maybe-open-connection (1) # File error: No device connected
15:53:15.449000 tramp-adb-get-ls-command (5) # Finding a suitable `ls' command
15:53:25.279000 tramp-file-name-handler (1) # Interrupt received in
operation (file-name-all-completions  /adb::/)


>
> 3rd test
> ========
>
> C-x C-f /adb:: <RET>
>   => "No device connected"

This also hangs until I externally kill the `adb' process

15:55:40.919000 tramp-adb-get-ls-command (5) # Finding a suitable `ls' command
15:56:01.929000 tramp-file-name-handler (1) # Interrupt received in operation (file-attributes /adb::/)
15:56:01.929000 tramp-file-name-handler (1) # Interrupt received in
operation (file-exists-p /adb::/)


Please keep in mind that I have to press ^G prior to killing the `adb'
process, of course, in order to "unhang" the Emacs process and to view
the *debug tramp/aadb * buffer

>
> So I cannot reproduce the problem. As usual, my local machine does not
> run MS Windows but Ubuntu; maybe this is the difference.
>
> Could you, please, tell exactly which key sequence you have used? And
> please use "emacs -Q" for your test.
>
> I have used the following Emacs version for test:
>
> GNU Emacs 24.3.50.20 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.13)
>  of 2013-03-09 on detlef
>
> Best regards, Michael.

bug#13299: 24.3.50; Tramp adb and device not found

[Michael Albinus]

nyc4bos@aol.com writes:

Hi,

>> C-x C-f /adb:: <TAB>
>>   => "[No match]"
>
> This creates the `adb' process and hangs for me.

Well, I've borrowed an MS Windows machine for tests. And indeed, it
blocks. Looks like `call-process' is not interruptable with a timer on
MS Windows.

I've changed the implementation of `tramp-adb-parse-device-names', using
`start-process' now. This seems to be OK.

Committed to the Emacs trunks as bzr revision #112067. Could you,
please, check?

Best regards, Michael.

bug#13299: 24.3.50; Tramp adb and device not found

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Sun, 17 Mar 2013 18:31:34 +0100
> Cc: 13299@debbugs.gnu.org
> 
> nyc4bos@aol.com writes:
> 
> Hi,
> 
> >> C-x C-f /adb:: <TAB>
> >>   => "[No match]"
> >
> > This creates the `adb' process and hangs for me.
> 
> Well, I've borrowed an MS Windows machine for tests. And indeed, it
> blocks. Looks like `call-process' is not interruptable with a timer on
> MS Windows.

What do you mean by "timer" here?  Even in Emacs this has multiple
meanings, to say nothing of the rest of the world ;-)

bug#13299: 24.3.50; Tramp adb and device not found

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> Well, I've borrowed an MS Windows machine for tests. And indeed, it
>> blocks. Looks like `call-process' is not interruptable with a timer on
>> MS Windows.
>
> What do you mean by "timer" here?  Even in Emacs this has multiple
> meanings, to say nothing of the rest of the world ;-)

There is the following code:

  (with-timeout (10)
    (with-temp-buffer
      (when (zerop (call-process tramp-adb-program nil t nil "devices"))
      ...

No problem under GNU/Linux. Under MS Windows, the timeout does not
interrupt the `call-process' form, when it is overdued. That's why I
have replaced it with a `start-process' implementation.

Best regards, Michael.

bug#13299: 24.3.50; Tramp adb and device not found

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: nyc4bos@aol.com,  13299@debbugs.gnu.org
> Date: Mon, 18 Mar 2013 08:33:19 +0100
> 
> > What do you mean by "timer" here?  Even in Emacs this has multiple
> > meanings, to say nothing of the rest of the world ;-)
> 
> There is the following code:
> 
>   (with-timeout (10)
>     (with-temp-buffer
>       (when (zerop (call-process tramp-adb-program nil t nil "devices"))
>       ...
> 
> No problem under GNU/Linux. Under MS Windows, the timeout does not
> interrupt the `call-process' form, when it is overdued. That's why I
> have replaced it with a `start-process' implementation.

Hmm... can you describe how this works on Posix platforms?  Once
call-process forks the child process, it is AFAICS blocked inside
waitpid, so how do Emacs timers (which are the basis for with-timeout)
succeed to run at all?  What am I missing?

bug#13299: 24.3.50; Tramp adb and device not found

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> There is the following code:
>> 
>>   (with-timeout (10)
>>     (with-temp-buffer
>>       (when (zerop (call-process tramp-adb-program nil t nil "devices"))
>>       ...
>> 
>> No problem under GNU/Linux. Under MS Windows, the timeout does not
>> interrupt the `call-process' form, when it is overdued. That's why I
>> have replaced it with a `start-process' implementation.
>
> Hmm... can you describe how this works on Posix platforms?  Once
> call-process forks the child process, it is AFAICS blocked inside
> waitpid, so how do Emacs timers (which are the basis for with-timeout)
> succeed to run at all?  What am I missing?

I haven't digged too much. Likely, it works under GNU/Linux because any
"adb devices" call returns in time, successful or not.

On MS Windows, the very first call of "adb devices" does not return in
the case no Android device is connected. Once adb runs on MS Windows,
any further call of "adb devices" returns in time.

So there is no difference in the timeout behaviour of Emacs. But since I
don't test on MS WIndows usually, it took that time to understand/fix
the problem for me.

Best regards, Michael.

bug#13299: 24.3.50; Tramp adb and device not found

[nyc4bos]

Michael Albinus <michael.albinus@gmx.de> writes:

Hi Michael,

> nyc4bos@aol.com writes:
>
> Hi,
>
>>> C-x C-f /adb:: <TAB>
>>>   => "[No match]"
>>
>> This creates the `adb' process and hangs for me.
>
> Well, I've borrowed an MS Windows machine for tests. And indeed, it
> blocks. Looks like `call-process' is not interruptable with a timer on
> MS Windows.
>
> I've changed the implementation of `tramp-adb-parse-device-names', using
> `start-process' now. This seems to be OK.
>
> Committed to the Emacs trunks as bzr revision #112067. Could you,
> please, check?

Yes, it works!

Thanks!

BTW, when you kill Emacs, the "adb fork-server server" process remains.

Is that what happens on GNU/Linux and Posix systems?

Can the be queried to kill that process?

Thanks.

>
> Best regards, Michael.

bug#13299: 24.3.50; Tramp adb and device not found

[Michael Albinus]

nyc4bos@aol.com writes:

> Hi Michael,

Hi,

> BTW, when you kill Emacs, the "adb fork-server server" process remains.
>
> Can the be queried to kill that process?

Why that? If you call adb.exe outside Emacs the first time, it also
spawns a process in the background, which won't be killed. There is no
reason to behave differently inside Emacs.

> Thanks.

Best regards, Michael.