Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.comp.microsoft.windows > #1511 > unrolled thread

Is there a way to put a command window in the background like Linux does (so that you can kill it)?

Back to article view | Back to alt.comp.microsoft.windows

Contents

  Is there a way to put a command window in the background like Linux does (so that you can kill it)? Andy Burnelli <spam@nospam.com> - 2022-04-21 18:42 +0100
    Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? "Kerr-Mudd, John" <admin@127.0.0.1> - 2022-04-21 20:43 +0100
      Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Andy Burnelli <spam@nospam.com> - 2022-04-21 21:57 +0100
        Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Herbert Kleebauer <klee@unibwm.de> - 2022-04-21 23:57 +0200
          Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Andy Burnelli <spam@nospam.com> - 2022-04-22 02:07 +0100
            Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Andy Burnelli <spam@nospam.com> - 2022-04-22 02:18 +0100
            Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Herbert Kleebauer <klee@unibwm.de> - 2022-04-22 07:45 +0200
              Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Andy Burnelli <spam@nospam.com> - 2022-04-22 09:32 +0100
                Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Andy Burns <usenet@andyburns.uk> - 2022-04-22 10:23 +0100
                  Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? MikeS <MikeS@fred.com> - 2022-04-22 13:06 +0100
                    Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? "Kerr-Mudd, John" <admin@127.0.0.1> - 2022-04-22 13:28 +0100
                Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Herbert Kleebauer <klee@unibwm.de> - 2022-04-22 13:40 +0200
                  Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Andy Burnelli <spam@nospam.com> - 2022-04-22 22:26 +0100
                    Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Herbert Kleebauer <klee@unibwm.de> - 2022-04-23 09:12 +0200
                      Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Andy Burnelli <spam@nospam.com> - 2022-04-23 13:36 +0100
                        Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Herbert Kleebauer <klee@unibwm.de> - 2022-04-23 17:04 +0200
                          Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Herbert Kleebauer <klee@unibwm.de> - 2022-04-23 17:07 +0200
                            Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Andy Burnelli <spam@nospam.com> - 2022-04-23 20:13 +0100
                            Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Andy Burnelli <spam@nospam.com> - 2022-07-20 19:56 +0100
                          Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Herbert Kleebauer <klee@unibwm.de> - 2022-04-23 17:15 +0200
                            Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Andy Burnelli <spam@nospam.com> - 2022-04-23 17:53 +0100
                          Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Andy Burnelli <spam@nospam.com> - 2022-04-23 17:22 +0100
                            Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Andy Burnelli <spam@nospam.com> - 2022-04-29 17:49 +0100
    Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Andy Burnelli <spam@nospam.com> - 2022-04-23 14:17 +0100
      Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Andy Burnelli <spam@nospam.com> - 2022-04-23 14:25 +0100
    Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Robert Roland <fake@ddress.no> - 2022-04-23 15:46 +0200
      Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Andy Burnelli <spam@nospam.com> - 2022-04-23 15:59 +0100
        Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Robert Roland <fake@ddress.no> - 2022-04-24 00:34 +0200
          Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Andy Burnelli <spam@nospam.com> - 2022-04-24 04:09 +0100
            Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Herbert Kleebauer <klee@unibwm.de> - 2022-04-24 18:07 +0200
              Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Andy Burnelli <spam@nospam.com> - 2022-04-25 01:06 +0100
      The various kinds of Windows applications... (Was: Is there a way to put a command window in the background like Linux does (so that you can kill it)?) gazelle@shell.xmission.com (Kenny McCormack) - 2022-04-24 12:44 +0000
        Re: The various kinds of Windows applications... (Was: Is there a way to put a command window in the background like Linux does (so that you can kill it)?) Andy Burnelli <spam@nospam.com> - 2022-04-27 12:14 +0100
    Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2022-04-24 00:19 +0800
      Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Andy Burnelli <spam@nospam.com> - 2022-04-29 16:54 +0100
    Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Andy Burnelli <spam@nospam.com> - 2022-04-27 12:19 +0100
    Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Andy Burnelli <spam@nospam.com> - 2022-07-17 11:39 +0100
      Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? gazelle@shell.xmission.com (Kenny McCormack) - 2022-07-17 15:17 +0000
        Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Andy Burnelli <spam@nospam.com> - 2022-07-18 06:46 +0100
          Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? "Kerr-Mudd, John" <admin@127.0.0.1> - 2022-07-18 08:20 +0100
            Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Andy Burnelli <spam@nospam.com> - 2022-07-18 08:56 +0100
            Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Andy Burnelli <spam@nospam.com> - 2022-07-20 19:53 +0100
              Re: Is there a way to put a command window in the background like Linux does (so that you can kill it)? Andy Burnelli <spam@nospam.com> - 2022-08-17 03:53 +0100

Page 1 of 3  [1] 2 3  Next page →

#1511 — Is there a way to put a command window in the background like Linux does (so that you can kill it)?

Is there a way to put a command window in the background like Linux does 
with the ampersand (so that you can kill the window but not the process)?

The problem that I have is I run a lot of commands from the Run icon in my
taskbar which bring up command windows to run scxripts but which leave
the unnecessary command window sitting around (which can be iconified).
 <https://i.postimg.cc/Y00vx4yp/scrcpy04.jpg> Extraneous cmd window (&)

As an example, for years I've been running commands from a shortcut target
such as this target below which end up leaving an open command window in the
taskbar after they call the process, which itself opens up its own window.
%comspec% /k cd /d "c:\app\editor\android\scrcpy" && adb connect 192.168.0.2:5555 && scrcpy --always-on-top --tcpip=192.168.0.2:5555

That reliably pops up the Android screen on Windows over Wi-Fi but then I
have absolutely no need for the command window to remain around as clutter.

Is there a way to get rid of the command Window and not kill the process?

In UNIX, I used to use the ampersand (&) to background the process.
The I could easily close the window & the background process would remain.

Does Windows have that concept of putting the command in the background so
that the window that called it can be closed (but the process remains)?

I have the same issue with openvpn windows where I don't need the extraneous
running open command window cluttering up what otherwise should be a clean
Windows user experience. I never enter another command in those windows.

And yet, I can accidentally interfere with the open window because it's
there and you can't get rid of it (other than to iconify it with the (-), 
but it's still there on the otherwise clean taskbar, just waiting to be 
opened by accident (and the icon looks like all other cmd window icons).

For those reasons... 

Is there a way to background a Windows command (e.g., "&") and then we can
safely _close_ that extraneous running command window to reduce clutter?
-- 
Usenet is where kind-hearted people daily gather to voluntarily help others.

[toc] | [next] | [standalone]

#1512

On Thu, 21 Apr 2022 18:42:52 +0100
Andy Burnelli <spam@nospam.com> wrote:

> Is there a way to put a command window in the background like Linux does 
> with the ampersand (so that you can kill the window but not the process)?
> 
> The problem that I have is I run a lot of commands from the Run icon in my
> taskbar which bring up command windows to run scxripts but which leave
> the unnecessary command window sitting around (which can be iconified).
>  <https://i.postimg.cc/Y00vx4yp/scrcpy04.jpg> Extraneous cmd window (&)
> 
> As an example, for years I've been running commands from a shortcut target
> such as this target below which end up leaving an open command window in the
> taskbar after they call the process, which itself opens up its own window.
> %comspec% /k cd /d "c:\app\editor\android\scrcpy" && adb connect 192.168.0.2:5555 && scrcpy --always-on-top --tcpip=192.168.0.2:5555
> 
> That reliably pops up the Android screen on Windows over Wi-Fi but then I
> have absolutely no need for the command window to remain around as clutter.
> 

So why put in the parameter '/k'?

> Is there a way to get rid of the command Window and not kill the process?
 
Just never open it in the first place?

> In UNIX, I used to use the ampersand (&) to background the process.
> The I could easily close the window & the background process would remain.
> 
> Does Windows have that concept of putting the command in the background so
> that the window that called it can be closed (but the process remains)?
> 
> I have the same issue with openvpn windows where I don't need the extraneous
> running open command window cluttering up what otherwise should be a clean
> Windows user experience. I never enter another command in those windows.
> 
> And yet, I can accidentally interfere with the open window because it's
> there and you can't get rid of it (other than to iconify it with the (-), 
> but it's still there on the otherwise clean taskbar, just waiting to be 
> opened by accident (and the icon looks like all other cmd window icons).
> 
> For those reasons... 
> 
> Is there a way to background a Windows command (e.g., "&") and then we can
> safely _close_ that extraneous running command window to reduce clutter?
> -- 
> Usenet is where kind-hearted people daily gather to voluntarily help others.


-- 
Bah, and indeed Humbug.

[toc] | [prev] | [next] | [standalone]

#1513

Kerr-Mudd, John wrote:

>> That reliably pops up the Android screen on Windows over Wi-Fi but then I
>> have absolutely no need for the command window to remain around as clutter.
>> 
> 
> So why put in the parameter '/k'?

Good question.

The /k is mostly habit but it doesn't matter as you must use either /K or /C 
and both do the exact same thing with respect to the window staying open.

%comspec% /c cd /d "c:\app\editor\android\scrcpy" && adb connect 192.168.0.2:5555 && scrcpy --always-on-top --tcpip=192.168.0.2:5555

As a direct result of your query, I changed it to /c (you must use one or
the other as far as I know), but I knew it wouldn't matter as I've had this
problem for decades. I just never tried to resolve it until now.

The way Linux gets around it is the put the command in the background.
But I don't know how to put a Windows command in the background.

Does anyone know how to background a Windows command?

There might be something in the help for comspec though on the Linux-like
use of ampersand (&) to put the process into the background so that the
initiating command window can subsequently be closed.
 %comspec% /? > comspec.man  (See output in the sig.)
 
>> Is there a way to get rid of the command Window and not kill the process?
>  
> Just never open it in the first place?

That would work if I knew how to run a command without ever opening a
command window. How is that done for the screen copy command shown above?
-- 
%comspec% /? > comspec.man 

Starts a new instance of the Windows command interpreter

CMD [/A | /U] [/Q] [/D] [/E:ON | /E:OFF] [/F:ON | /F:OFF] [/V:ON | /V:OFF]
    [[/S] [/C | /K] string]

/C      Carries out the command specified by string and then terminates
/K      Carries out the command specified by string but remains
/S      Modifies the treatment of string after /C or /K (see below)
/Q      Turns echo off
/D      Disable execution of AutoRun commands from registry (see below)
/A      Causes the output of internal commands to a pipe or file to be ANSI
/U      Causes the output of internal commands to a pipe or file to be
        Unicode
/T:fg   Sets the foreground/background colors (see COLOR /? for more info)
/E:ON   Enable command extensions (see below)
/E:OFF  Disable command extensions (see below)
/F:ON   Enable file and directory name completion characters (see below)
/F:OFF  Disable file and directory name completion characters (see below)
/V:ON   Enable delayed environment variable expansion using ! as the
        delimiter. For example, /V:ON would allow !var! to expand the
        variable var at execution time.  The var syntax expands variables
        at input time, which is quite a different thing when inside of a FOR
        loop.
/V:OFF  Disable delayed environment expansion.

Note that multiple commands separated by the command separator '&&'
are accepted for string if surrounded by quotes.  Also, for compatibility
reasons, /X is the same as /E:ON, /Y is the same as /E:OFF and /R is the
same as /C.  Any other switches are ignored.

If /C or /K is specified, then the remainder of the command line after
the switch is processed as a command line, where the following logic is
used to process quote (") characters:

    1.  If all of the following conditions are met, then quote characters
        on the command line are preserved:

        - no /S switch
        - exactly two quote characters
        - no special characters between the two quote characters,
          where special is one of: &<>()@^|
        - there are one or more whitespace characters between the
          two quote characters
        - the string between the two quote characters is the name
          of an executable file.

    2.  Otherwise, old behavior is to see if the first character is
        a quote character and if so, strip the leading character and
        remove the last quote character on the command line, preserving
        any text after the last quote character.

If /D was NOT specified on the command line, then when CMD.EXE starts, it
looks for the following REG_SZ/REG_EXPAND_SZ registry variables, and if
either or both are present, they are executed first.

    HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\AutoRun

        and/or

    HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun

Command Extensions are enabled by default.  You may also disable
extensions for a particular invocation by using the /E:OFF switch.  You
can enable or disable extensions for all invocations of CMD.EXE on a
machine and/or user logon session by setting either or both of the
following REG_DWORD values in the registry using REGEDIT.EXE:

    HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\EnableExtensions

        and/or

    HKEY_CURRENT_USER\Software\Microsoft\Command Processor\EnableExtensions

to either 0x1 or 0x0.  The user specific setting takes precedence over
the machine setting.  The command line switches take precedence over the
registry settings.

In a batch file, the SETLOCAL ENABLEEXTENSIONS or DISABLEEXTENSIONS
arguments
takes precedence over the /E:ON or /E:OFF switch. See SETLOCAL /? for
details.

The command extensions involve changes and/or additions to the following
commands:

    DEL or ERASE
    COLOR
    CD or CHDIR
    MD or MKDIR
    PROMPT
    PUSHD
    POPD
    SET
    SETLOCAL
    ENDLOCAL
    IF
    FOR
    CALL
    SHIFT
    GOTO
    START (also includes changes to external command invocation)
    ASSOC
    FTYPE

To get specific details, type commandname /? to view the specifics.

Delayed environment variable expansion is NOT enabled by default.  You
can enable or disable delayed environment variable expansion for a
particular invocation of CMD.EXE with the /V:ON or /V:OFF switch.  You
can enable or disable delayed expansion for all invocations of CMD.EXE on a
machine and/or user logon session by setting either or both of the
following REG_DWORD values in the registry using REGEDIT.EXE:

    HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\DelayedExpansion

        and/or

    HKEY_CURRENT_USER\Software\Microsoft\Command Processor\DelayedExpansion

to either 0x1 or 0x0.  The user specific setting takes precedence over
the machine setting.  The command line switches take precedence over the
registry settings.

In a batch file the SETLOCAL ENABLEDELAYEDEXPANSION or
DISABLEDELAYEDEXPANSION
arguments takes precedence over the /V:ON or /V:OFF switch. See SETLOCAL /?
for details.

If delayed environment variable expansion is enabled, then the exclamation
character can be used to substitute the value of an environment variable
at execution time.

You can enable or disable file name completion for a particular
invocation of CMD.EXE with the /F:ON or /F:OFF switch.  You can enable
or disable completion for all invocations of CMD.EXE on a machine and/or
user logon session by setting either or both of the following REG_DWORD
values in the registry using REGEDIT.EXE:

    HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\CompletionChar
    HKEY_LOCAL_MACHINE\Software\Microsoft\Command
Processor\PathCompletionChar

        and/or

    HKEY_CURRENT_USER\Software\Microsoft\Command Processor\CompletionChar
    HKEY_CURRENT_USER\Software\Microsoft\Command
Processor\PathCompletionChar

with the hex value of a control character to use for a particular
function (e.g.  0x4 is Ctrl-D and 0x6 is Ctrl-F).  The user specific
settings take precedence over the machine settings.  The command line
switches take precedence over the registry settings.

If completion is enabled with the /F:ON switch, the two control
characters used are Ctrl-D for directory name completion and Ctrl-F for
file name completion.  To disable a particular completion character in
the registry, use the value for space (0x20) as it is not a valid
control character.

Completion is invoked when you type either of the two control
characters.  The completion function takes the path string to the left
of the cursor appends a wild card character to it if none is already
present and builds up a list of paths that match.  It then displays the
first matching path.  If no paths match, it just beeps and leaves the
display alone.  Thereafter, repeated pressing of the same control
character will cycle through the list of matching paths.  Pressing the
Shift key with the control character will move through the list
backwards.  If you edit the line in any way and press the control
character again, the saved list of matching paths is discarded and a new
one generated.  The same occurs if you switch between file and directory
name completion.  The only difference between the two control characters
is the file completion character matches both file and directory names,
while the directory completion character only matches directory names.
If file completion is used on any of the built in directory commands
(CD, MD or RD) then directory completion is assumed.

The completion code deals correctly with file names that contain spaces
or other special characters by placing quotes around the matching path.
Also, if you back up, then invoke completion from within a line, the
text to the right of the cursor at the point completion was invoked is
discarded.

The special characters that require quotes are:
     <space>
     &()[]{}^=;!'+,`~

[toc] | [prev] | [next] | [standalone]

#1514

On 21.04.2022 22:57, Andy Burnelli wrote:
> Kerr-Mudd, John wrote:
> 
>>> That reliably pops up the Android screen on Windows over Wi-Fi but then I
>>> have absolutely no need for the command window to remain around as clutter.
>>> 
>> 
>> So why put in the parameter '/k'?
> 
> Good question.
> 
> The /k is mostly habit but it doesn't matter as you must use either /K or /C
> and both do the exact same thing with respect to the window staying open.
> 
> %comspec% /c cd /d "c:\app\editor\android\scrcpy" && adb connect 192.168.0.2:5555 && scrcpy --always-on-top --tcpip=192.168.0.2:5555
> 
> As a direct result of your query, I changed it to /c (you must use one or
> the other as far as I know), but I knew it wouldn't matter as I've had this
> problem for decades. I just never tried to resolve it until now.

It should matter. But I suppose scrcpy is a GUI program which will not
terminate itself. But if you exit scrcpy, then the CMD should also be closed.
If you don't want that the CMD windows stays open, then use "start scrcpy".

[toc] | [prev] | [next] | [standalone]

#1515

Herbert Kleebauer wrote:

> It should matter. 

Well, to be clear, the "/c" vs "/k" matters sometimes. 
But not in the case of GUI programs, as you already surmised. 

> But I suppose scrcpy is a GUI program which will not
> terminate itself. 

If I terminate the mirrored Android GUI window, the command window stays
open even as the scrcpy command running inside of it exits. If I instead
terminate that command window, then both the command window and the scrcpy
mirrored GUI are terminated.

> But if you exit scrcpy, then the CMD should also be closed.

In Linux, I'd simply add an ampersand (&) to the end of the scrcpy command.
That backgrounds the command such that killing the command window doesn't
affect any process which is running in the background (which then can be
brought to the fore when needed).

> If you don't want that the CMD windows stays open, then use "start scrcpy".

Hmmmmm.... gonna have to look that one up... and test to see if that works.

<https://stackoverflow.com/questions/8121238/start-comspec-c-script-cmd-vs-start-cmd-c-script-cmd>
 "What is the difference between following commands:"
 "start %comspec% /c script.cmd
 "start cmd /C script.cmd"
 "I need that cmd window for script.cmd should close automatically
  when script.cmd is finished."
Drat. It's the right question, but all the "answers" are off topic.
(And the OP didn't chastise them for that. So there's no answer there.)

Given "Win+R > start" fails to find the executable, let me look for the
path... oh, geez, it's not an exexcutable in the normal sense of the word.
 dir /s/a/l/on/b C:\Windows\*.* | findstr "start"

Ah! "start" is a special _internal_ command (much like "ver" is internal).
 <https://www.computerhope.com/jargon/i/intecomm.htm>

That means "start" works _only_ inside an existing command window.
 <https://www.computerhope.com/starthlp.htm>

So there's no way to use "start" without _first_ opening a command window.

I'm working on getting the syntax right to either call the shortcut.lnk
directly from the "Run" icon pinned to my taskbar, or, failing that, to pass
the "start" to the command window via the "Run" icon pinned to my taskbar.

The syntax isn't as easy to figure out as I would have thought due to the
parallel nature of the run command, complicated by the fact it is an
"internal command" so it only works _after_ the command window is opened. 
-- 
<https://ss64.com/nt/start.html>
<https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/start>
<https://www.howtogeek.com/tips/how-to-run-a-scheduled-task-without-a-command-window-appearing/>
<https://www.windows-commandline.com/cmd-start-command/>

[toc] | [prev] | [next] | [standalone]

#1516

Andy Burnelli wrote:

> The syntax isn't as easy to figure out as I would have thought due to the
> parallel nature of the run command, complicated by the fact it is an
> "internal command" so it only works _after_ the command window is opened.


Ooops. To be clear... I meant the "start" command is parallel in nature.

Anyway, the problem is the parallel start syntax won't work in the Windows
Run box or in the shortcut TARGET field (so far, anyway on my need for a
linear "cd & adb & scrcpy" command sequence).

Working on that syntax right now... but if you've never tried to use the
internal "start" command, you might not realize that it fails 100% of the
time (so far) if you haven't figured out its arcane syntax requirements
(which I haven't figured out yet).

As one syntax example, apparently "start" _must_ be used _only_ with "/k".
 <https://ss64.com/nt/start.html>
Otherwise, there's nothing left for remaining commands to run inside of.

And if you google for start syntax examples, they're all too simple:
 <https://www.windows-commandline.com/cmd-start-command/>
Bear in mind, zero of these examples work in the "Run" box (so far anyway).

[toc] | [prev] | [next] | [standalone]

#1518

On 22.04.2022 03:07, Andy Burnelli wrote:

> 
>> If you don't want that the CMD windows stays open, then use "start scrcpy".
> 
> Hmmmmm.... gonna have to look that one up... and test to see if that works.

start /?

Why don't you just try your command with an added "start" before "scrcpy":

%comspec% /c cd /d "c:\app\editor\android\scrcpy" && adb connect 192.168.0.2:5555 && start scrcpy --always-on-top --tcpip=192.168.0.2:5555

If the CMD window still doesn't close, add a "&cls&exit"

[toc] | [prev] | [next] | [standalone]

#1519

Herbert Kleebauer wrote:

>>> If you don't want that the CMD windows stays open, then use "start scrcpy".
>> 
>> Hmmmmm.... gonna have to look that one up... and test to see if that works.
> 
> start /?

I think perhaps this task of killing the window is harder than it seems to be.

I ran that and I referenced all the online manpages; however, I haven't
_understood_ yet all the options, nor have I figured out which will work.

> Why don't you just try your command with an added "start" before "scrcpy":
> %comspec% /c cd /d "c:\app\editor\android\scrcpy" && adb connect 192.168.0.2:5555 && start scrcpy --always-on-top --tcpip=192.168.0.2:5555

Well, that _was_ the first thing I had tried; but all it did when I tried it
was _add_ another command window (which closed instantly); but otherwise
there was no change (in that what's left is the command window & the Android mirror).
 
> If the CMD window still doesn't close, add a "&cls&exit"

I think it may be harder to do than it at first appears to be.

%comspec% /c cd /d "c:\app\editor\android\scrcpy" && adb connect 192.168.0.2:5555 && start scrcpy --always-on-top --tcpip=192.168.0.2:5555 & cls & exit
%comspec% /c cd /d "c:\app\editor\android\scrcpy" && adb connect 192.168.0.2:5555 && start scrcpy --always-on-top --tcpip=192.168.0.2:5555 & exit
%comspec% /c cd /d "c:\app\editor\android\scrcpy" & adb connect 192.168.0.2:5555 & cls & start scrcpy --always-on-top --tcpip=192.168.0.2:5555 & cls & exit
Unfortunately they still left the command window the same as before.

What they apparently killed was the penultimate adb server window 
(whose standard out used to be combined with the scrcpy window apparently).

However clearing the screen and exiting _again_ didn't solve that issue
of the lingering command window when run from the "Run" icon:
%comspec% /c cd /d "c:\app\editor\android\scrcpy" & adb connect 192.168.0.2:5555 & cls & start scrcpy --always-on-top --tcpip=192.168.0.2:5555 & cls & exit & cls & exit
%comspec% /c cd /d "c:\app\editor\android\scrcpy" & adb connect 192.168.0.2:5555 & start scrcpy --always-on-top --tcpip=192.168.0.2:5555 & cls & exit & cls & exit
%comspec% /c cd /d "c:\app\editor\android\scrcpy" & adb connect 192.168.0.2:5555 & start scrcpy --always-on-top --tcpip=192.168.0.2:5555 & cls & exit & exit

It's interesting that with the &cls&exit, the adb output is missing; 
but it still doesn't prevent the command window from lingering. Sigh.
-- 
 &    separates commands on a line.
 &&   executes this command only if previous command's errorlevel is 0.
 ||   (not used above) executes this command only if previous command's errorlevel is NOT 0
 >    output to a file
 >>   append output to a file
 <    input from a file
 |    output of one command into the input of another command
 ^    escapes any of the above, including itself, if needed to be passed to a program
 "    parameters with spaces must be enclosed in quotes
 +    used with copy to concatenate files. E.G. copy file1+file2 newfile
 ,    used with copy to indicate missing parameters. This updates the files modified date. E.G. copy /b file1,,
 %variablename% a inbuilt or user set environmental variable
 !variablename! a user set environmental variable expanded at execution time, turned with SetLocal EnableDelayedExpansion command
 %<number> (%1) the nth command line parameter passed to a batch file. %0 is the batchfile's name.
 %* (%*) the entire command line.
 %<a letter> or %%<a letter> (%A or %%A) the variable in a for loop. Single % sign at command prompt and double % sign in a batch file.

[toc] | [prev] | [next] | [standalone]

#1520

Andy Burnelli wrote:

> I think it may be harder to do than it at first appears to be.

You're trying to do stuff that's kind of beyond CMD's capability, you can do 
more with WSH (windows script host) or Powershell, if you haven't used WSH 
before, I wouldn't recommend starting now, it's a dead-end.

A starting point, if it's of interest, there are many other ways to skin the cat

<https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/start-process?view=powershell-7.2>

[toc] | [prev] | [next] | [standalone]

#1522

On 22/04/2022 10:23, Andy Burns wrote:
> Andy Burnelli wrote:
> 
>> I think it may be harder to do than it at first appears to be.
> 
> You're trying to do stuff that's kind of beyond CMD's capability, you 
> can do more with WSH (windows script host) or Powershell, if you haven't 
> used WSH before, I wouldn't recommend starting now, it's a dead-end.
> 
> A starting point, if it's of interest, there are many other ways to skin 
> the cat
> 
> <https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/start-process?view=powershell-7.2> 
> 
> 
I do what I think the OP wants by using this free utility:
https://www.robvanderwoude.com/files/consolestate.zip
https://www.robvanderwoude.com/helptext.php?src=consolestate_cs_help

A simple command line would be:
%comspec% /k cd /d "D:\" && consolestate.exe /Hide && Notepad.exe
which will run Notepad and leave it open but hide the command window.

[toc] | [prev] | [next] | [standalone]

#1523

On Fri, 22 Apr 2022 13:06:39 +0100
MikeS <MikeS@fred.com> wrote:

> On 22/04/2022 10:23, Andy Burns wrote:
> > Andy Burnelli wrote:
> > 
> >> I think it may be harder to do than it at first appears to be.
> > 
> > You're trying to do stuff that's kind of beyond CMD's capability, you 
> > can do more with WSH (windows script host) or Powershell, if you haven't 
> > used WSH before, I wouldn't recommend starting now, it's a dead-end.
> > 
> > A starting point, if it's of interest, there are many other ways to skin 
> > the cat
> > 
> > <https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/start-process?view=powershell-7.2> 
> > 
> > 
> I do what I think the OP wants by using this free utility:
> https://www.robvanderwoude.com/files/consolestate.zip
> https://www.robvanderwoude.com/helptext.php?src=consolestate_cs_help

requires .Net

Just saying.
> 
> A simple command line would be:
> %comspec% /k cd /d "D:\" && consolestate.exe /Hide && Notepad.exe
> which will run Notepad and leave it open but hide the command window.


-- 
Bah, and indeed Humbug.

[toc] | [prev] | [next] | [standalone]

#1521

On 22.04.2022 10:32, Andy Burnelli wrote:
> Herbert Kleebauer wrote:
>
>> Why don't you just try your command with an added "start" before "scrcpy":
>> %comspec% /c cd /d "c:\app\editor\android\scrcpy" && adb connect 192.168.0.2:5555 && start scrcpy --always-on-top --tcpip=192.168.0.2:5555

I don't know how you enter this command. If you type <WIN>R and enter the
following line:

  %comspec% /c cd /d "c:\app\editor\android\scrcpy" && start notepad

notepad is started and the CMD window then closed. If you remove the
"start", the CMD window stays open until you exit notepad.

If you enter this command in an already open CMD window, then
it doesn't make any sense to start a new CMD window, just start a
batch with this content (or directly type the lines in the
open CMD window):

cd /d "c:\app\editor\android\scrcpy"
adb connect 192.168.0.2:5555
start scrcpy --always-on-top --tcpip=192.168.0.2:5555
exit

[toc] | [prev] | [next] | [standalone]

#1524

Herbert Kleebauer wrote:

>>> Why don't you just try your command with an added "start" before "scrcpy":
>>> %comspec% /c cd /d "c:\app\editor\android\scrcpy" && adb connect 192.168.0.2:5555 && start scrcpy --always-on-top --tcpip=192.168.0.2:5555
> 
> I don't know how you enter this command. 

Thanks for asking where I first test it in Win+R (only I have the "Run" icon pinned to my taskbar as shown in the graphic previously presented).
 <https://i.postimg.cc/tTmdgKTB/scrcpy02.jpg> An efficient program setup

Once it works in the "Run" box, then I put it into a shortcut TARGET field.
(See the graphic above and below for those steps, as previously documented.)
 <https://i.postimg.cc/Vvrq0K0m/scrcpy03.jpg> The efficient setup explained

> If you type <WIN>R and enter the
> following line:
> 
>   %comspec% /c cd /d "c:\app\editor\android\scrcpy" && start notepad
> 
> notepad is started and the CMD window then closed.

Yup. But that's so easy, this does something similar but w/o the cmd window _needing_ to be opened (the point being that's far too easy of an example).
 <https://i.postimg.cc/m2mYw789/notepad01.jpg>

 Win+R > xx
 Where "xx" is previously defined in the Windows registry for efficency as:
 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\xx.exe
 @Default === C:\app\editor\txt\notepad++\notepad++.exe
 
For whatever reason, with the scrcpy command (which has to have adb prior), 
it's not as easy to do as I would have hoped it would be, unfortunately.

> If you remove the
> "start", the CMD window stays open until you exit notepad.

I understand, but I think this is a deeper level problem set than the mere opening of a graphical tool. 

An hint of the added layer of complexity is that when I used the start and killed the command window like you kindly had suggested, I noticed that the "adb" stdout didn't show up anymore in the remaining window (and, that a third window popped up and died instantly), and that the exit caused the stdout from adb (not scrcpy mind you, but adb) to be missing.

I know this because without the "start" & "&exit" stuff, adb would stay in the scrcpy command window and the kill-server of adb would also stay when the mirrored Android window was closed.

But with the "start" & "&exit", both of those stdout outputs disappeared.
(Clearly they were being fed to a window that was already closed.)

The point being that this is a bit more complicated than people think it is.
 
> If you enter this command in an already open CMD window, then
> it doesn't make any sense to start a new CMD window, just start a
> batch with this content (or directly type the lines in the
> open CMD window):
> 
> cd /d "c:\app\editor\android\scrcpy"
> adb connect 192.168.0.2:5555
> start scrcpy --always-on-top --tcpip=192.168.0.2:5555
> exit

Let's keep in mind that efficiency and simplicity is the goal, always.
Let's try the sequence above to see what it does:

0. With the phone fifty feet away on a charger (but on Wi-Fi)
1. Run > cmd  
2. C:\> ping 192.168.0.2 (don't worry about this technicality)
3. cd /d "c:\app\editor\android\scrcpy"
4. adb kill-server (don't worry about that technicality)
5. adb connect 192.168.0.2:5555
   * daemon not running; starting now at tcp:5037
   * daemon started successfully
   connected to 192.168.0.2:5555
6. start scrcpy --always-on-top --tcpip=192.168.0.2:5555

BTW, I probably do not need to specify the port the second 
time in that sequence above; but I do it twice just in case.

Note that brings up two windows, one of which is the mirrored
Android window, and the other of which is the "scrcpy.exe" command window:
 c:\app\editor\android\scrcpy\scrcpy.exe <== in the title bar
 scrcpy 1.23 <https://github.com/Genymobile/scrcpy>
 INFO: Connecting to 192.168.0.2:5555...
 INFO: Connected to 192.168.0.2:5555
 c:\app\editor\android\scrcpy\scrcpy-server: 1 file pushed, 0 skipped. 41.2 MB/s (41123 bytes in 0.001s)
 [server] INFO: Device: samsung SM-A326U (Android 11)
 INFO: Renderer: direct3d
 INFO: Initial texture: 720x1600

Then I click the cursor to make the focus the command window & type:
7. exit

No go. You can't type _anything_ into the command window. 
Nothing takes. 

I had never _tried_ it before; but try as I might, the _only_ thing 
you can do in that scrcpy command window is operate the Windows 
border X box [x] and iconify box [-] and largify box [o].

I repeat. There is no possibility of typing _anything_ in that
scrcpy opened command window. I didn't know that before now.

Thank you for edifying me as I try _all_ reasonable suggestions.
And I report back what I found out (like all good netizens should).

In summary, I don't think this is as easy as it appears to be.
-- 
Usenet is where kind-hearted people daily gather to voluntarily help others.

[toc] | [prev] | [next] | [standalone]

#1525

On 22.04.2022 23:26, Andy Burnelli wrote:

> Note that brings up two windows, one of which is the mirrored
> Android window, and the other of which is the "scrcpy.exe" command window:

Then scrcpy.exe uses both, a GUI window and a console. But that has
nothing to do with the CMD window. You can't close this console because
the program needs it (maybe for some status or error output).

If you start scrcpy.exe by a mouse click, both windows should be created.
If you start it within a CMD window, scrcpy.exe should use the CMD
window as console, so no new console is created and CMD is suspended until
scrcpy.exe is closed. If you start it with "start scrcpy.exe" in a cmd
window, then a new console is created and CMD get control back over its
console immediately.

[toc] | [prev] | [next] | [standalone]

#1526

Herbert Kleebauer wrote:

>> Note that brings up two windows, one of which is the mirrored
>> Android window, and the other of which is the "scrcpy.exe" command window:
> 
> Then scrcpy.exe uses both, a GUI window and a console. 
> But that has nothing to do with the CMD window.

Everything you said is correct. 
Hence I apologize for being confused prior. Thank you for clarifying. 

You (and Andy Burns) know more about Windows & command actions than I ever
will know, so I sincerely want to thank you for your kind-hearted help.

You are right. I was wrong. I ran all your tests (see below) and they worked
_exactly_ as you surmised they would.

> You can't close this console because
> the program needs it (maybe for some status or error output).

Yes. You are correct. I will give up on trying to close the "scrcpy console"
as the developers, for whatever reason, _want_ it to remain visible.

It's rare for me to fail to wrest control of Windows, but in this case, I
will admit defeat in that I can't get rid of that "scrcpy console" window
(other than to iconify it).

> If you start scrcpy.exe by a mouse click, both windows should be created.

You are correct. 
The total number of windows depends on _how_ I run the command.

1. There is whatever "thing" the command is run inside of
   a. That can be a CMD window
   b. That can be a RUN box
   c. That can be a shortcut TARGET
2. Then there is the "scrcpy console" window.
3. And then there is the resulting Android GUI.

As you correctly surmised, depending on _where_ I execute the scrcpy
command, the result could be two or three windows; but in every case, I
can't "kill" the scrcpy console (which was my original goal).

> If you start it within a CMD window, scrcpy.exe should use the CMD
> window as console, so no new console is created and CMD is suspended until
> scrcpy.exe is closed. 

This is correct.

Here is a step-by-step test with the phone on the Wi-Fi network.
A. Run > cmd
B. ping 192.168.0.2 (just to ensure the TCP/IP connection is alive)
C. cd c:\app\editor\android\scrcpy
D. adb kill-server (this gives me a known baseline starting point)
E. adb connect 192.168.0.2:5555 (this returns me to the cmd prompt)
F. scrcpy (the CMD window turns into a scrcpy console)

As you correctly surmised, that does _two_ things:
1. The "scrcpy" console takes over the CMD window.
2. The Android GUI pops up

Then, when I press the Windows [x] box in the Android GUI...
1. That [x] kills the Android GUI window
2. And it kills the scrcpy process in the CMD window
3. Which gets me back the command prompt in the CMD window

> If you start it with "start scrcpy.exe" in a cmd
> window, then a new console is created and CMD get control back over its
> console immediately.

You are correct.

Here is a step-by-step test with the phone on the Wi-Fi network.
A. Run > cmd
B. ping 192.168.0.2 
C. cd c:\app\editor\android\scrcpy
D. adb kill-server 
E. adb connect 192.168.0.2:5555 (this returns me to the cmd prompt)
F. start scrcpy (this opens up a _separate_ scrcpy console)

That does _three_ things:
1. It opens up a _new_ console for the "scrcpy" output.
2. The Android GUI pops up
3. And it returns me to the cmd prompt in the cmd window
   (I can close that command window without affecting anything else.)

Likewise, three windows open up if I put this in a shortcut TARGET:
TARGET=%comspec% /k cd /d "c:\app\editor\android\scrcpy" && adb connect 192.168.0.2:5555 && start scrcpy --always-on-top --tcpip=192.168.0.2:5555
a. It opens a cmd window 
b. It opens a separate scrcpy console
c. It opens the Android GUI

The cmd window can be killed separately but killing either the Android GUI
or the scrpcpy console will kill both.

Lastly, this opens up three windows but instantly kills one of them: 
TARGET=%comspec% /k cd /d "c:\app\editor\android\scrcpy" && adb connect 192.168.0.2:5555 && start scrcpy --always-on-top --tcpip=192.168.0.2:5555 &cls&exit
a. It opens a cmd window 
b. It opens a separate scrcpy console
c. It opens the Android GUI
d. Then it kills the cmd window

In summary, you were always correct and I was confused - but in the end, I
agree with you on everything you've tried to help me to understand.

The net is that I can't easily get rid of the scrcpy console.
Thanks for your kind help and advice.

[toc] | [prev] | [next] | [standalone]

#1531

On 23.04.2022 14:36, Andy Burnelli wrote:

> The net is that I can't easily get rid of the scrcpy console.

I don't understand why you want to hide the console, but this
should do it (untested, I don't have a program which uses
a GUI window and a console). Just start the below batch.
If it works, you can store showwin.exe somewhere in your
PATH, so you don't have to create it temporarily every
time you execute the batch. I post the usage of showwin.exe
in a follow up.


@echo off
certutil -f -decode %~f0 showwin.exe>nul

cd /d "c:\app\editor\android\scrcpy"
adb connect 192.168.0.2:5555

:: now we hide console window
showwin.exe 0

scrcpy --always-on-top --tcpip=192.168.0.2:5555

:: after scrcpy is closed we show console window again
showwin.exe 5

del showwin.exe
goto :eof

-----BEGIN CERTIFICATE-----
TVpgAQEAAAAEAAAA//8AAGABAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAoAAAAA4fug4AtAnNIbgBTM0hTmljZSB0byBtZWV0IHNvbWVi
b2R5IHdobyBpcyBzdGlsbCB1c2luZyBET1MsDQpidXQgdGhpcyBwcm9ncmFtIHJl
cXVpcmVzIFdpbjMyLg0KJFBFAABMAQEAUHmlNgAAAAAAAAAA4AAPAQsBBQwAAgAA
AAAAAAAAAADIEAAAABAAAAAgAAAAAEAAABAAAAACAAAFAAAAAAAAAAQAAAAAAAAA
ACAAAAACAAAAAAAAAwAAAAAAEAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAA
GBAAADwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAYAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALnRleHQAAAAmAQAAABAAAAACAAAAAgAA
AAAAAAAAAAAAAAAAIAAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoEAAAAAAAAJQQAACmEAAA
uhAAAAAAAABgEAAAAAAAAAAAAABUEAAAABAAAIQQAAAAAAAAAAAAAHYQAAAIEAAA
AAAAAAAAAAAAAAAAAAAAAAAAAABVU0VSMzIuZGxsAABoEAAAAAAAAAAAU2hvd1dp
bmRvdwAAS0VSTkVMMzIuZGxsAACUEAAAphAAALoQAAAAAAAAAABHZXRDb21tYW5k
TGluZUEAAABHZXRDb25zb2xlV2luZG93AAAAAEV4aXRQcm9jZXNzAP8VCBBAADHS
SECAOAB0EYA4InUC99IJ0nXvgDggdepAMfa9BQAAAA+2EEAI0nQTgOowcvOA+gl3
7mv2CgHWMe3r5QntdAKJ7v8VDBBAAFZQ/xUAEEAAagD/FRAQQAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAA==
-----END CERTIFICATE-----

[toc] | [prev] | [next] | [standalone]

#1532

On 23.04.2022 17:04, Herbert Kleebauer wrote:

> I post the usage of showwin.exe

@echo off
:: minimize/maximize/hide the command window (requires W2k or better).
::
:: Usage:  showwin.exe number
::
::  0 SW_HIDE
::    Hides the window and activates another window.
::
::  1 SW_SHOWNORMAL
::    Activates and displays a window. If the window is minimized or maximized,
::    the system restores it to its original size and position. An application
::    should specify this flag when displaying the window for the first time.
::
::  2 SW_SHOWMINIMIZED
::    Activates the window and displays it as a minimized window.
::
::  3 SW_MAXIMIZE
::    Maximizes the specified window.
::
::  3 SW_SHOWMAXIMIZED
::    Activates the window and displays it as a maximized window.
::
::  4 SW_SHOWNOACTIVATE
::    Displays a window in its most recent size and position. This value is
::    similar to SW_SHOWNORMAL, except the window is not actived.
::
::  5 SW_SHOW
::    Activates the window and displays it in its current size and position.
::
::  6 SW_MINIMIZE
::    Minimizes the specified window and activates the next top-level window
::    in the Z order.
::
::  7 SW_SHOWMINNOACTIVE
::    Displays the window as a minimized window. This value is similar to
::    SW_SHOWMINIMIZED, except the window is not activated.
::
::  8 SW_SHOWNA
::    Displays the window in its current size and position. This value is
::    similar to SW_SHOW, except the window is not activated.
::
::  9 SW_RESTORE
::    Activates and displays the window. If the window is minimized or maximized,
::    the system restores it to its original size and position. An application
::    should specify this flag when restoring a minimized window.
::
:: 10 SW_SHOWDEFAULT
::    Sets the show state based on the SW_ value specified in the STARTUPINFO
::    structure passed to the CreateProcess function by the program that
::    started the application.
::
:: 11 SW_FORCEMINIMIZE
::    Windows 2000/XP: Minimizes a window, even if the thread that owns the
::    window is not responding. This flag should only be used when minimizing
::    windows from a different thread.


certutil -f -decode %~f0 showwin.exe>nul

cls
dir
:: wait 4 seconds
ping -n 4 localhost >nul
:: hide window
showwin.exe 0
dir /b
:: wait 4 seconds
ping -n 4 localhost >nul
:: show window
showwin.exe 5
:: wait 4 seconds
ping -n 4 localhost >nul
del showwin.exe
goto :eof

-----BEGIN CERTIFICATE-----
TVpgAQEAAAAEAAAA//8AAGABAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAoAAAAA4fug4AtAnNIbgBTM0hTmljZSB0byBtZWV0IHNvbWVi
b2R5IHdobyBpcyBzdGlsbCB1c2luZyBET1MsDQpidXQgdGhpcyBwcm9ncmFtIHJl
cXVpcmVzIFdpbjMyLg0KJFBFAABMAQEAUHmlNgAAAAAAAAAA4AAPAQsBBQwAAgAA
AAAAAAAAAADIEAAAABAAAAAgAAAAAEAAABAAAAACAAAFAAAAAAAAAAQAAAAAAAAA
ACAAAAACAAAAAAAAAwAAAAAAEAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAA
GBAAADwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAYAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALnRleHQAAAAmAQAAABAAAAACAAAAAgAA
AAAAAAAAAAAAAAAAIAAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoEAAAAAAAAJQQAACmEAAA
uhAAAAAAAABgEAAAAAAAAAAAAABUEAAAABAAAIQQAAAAAAAAAAAAAHYQAAAIEAAA
AAAAAAAAAAAAAAAAAAAAAAAAAABVU0VSMzIuZGxsAABoEAAAAAAAAAAAU2hvd1dp
bmRvdwAAS0VSTkVMMzIuZGxsAACUEAAAphAAALoQAAAAAAAAAABHZXRDb21tYW5k
TGluZUEAAABHZXRDb25zb2xlV2luZG93AAAAAEV4aXRQcm9jZXNzAP8VCBBAADHS
SECAOAB0EYA4InUC99IJ0nXvgDggdepAMfa9BQAAAA+2EEAI0nQTgOowcvOA+gl3
7mv2CgHWMe3r5QntdAKJ7v8VDBBAAFZQ/xUAEEAAagD/FRAQQAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAA==
-----END CERTIFICATE-----



The source code:

winmain::
         jsr.l   (GetCommandLine)
                                 ; skip program name
         eor.l   r1,r1           ; not within "" flag
         dec.l   r0
_20:    inc.l   r0
         cmp.b   #0,(r0)
         beq.b   _10
         cmp.b   #'"',(r0)
         bne.b   _30
         not.l   r1
_30:    or.l    r1,r1
         bne.b   _20
         cmp.b   #' ',(r0)
         bne.b   _20
         inc.l   r0

_10:    eor.l   r5,r5
         move.l  #5,r4           ; default: SW_SHOW
_50:    movu.bl (r0),r1
         inc.l   r0
         or.b    r1,r1
         beq.b   _40
         sub.b   #'0',r1
         bcs.b   _50
         cmp.b   #9,r1
         bhi.b   _50
         mulsq.l #10,r5,r5
         add.l   r1,r5
         eor.l   r4,r4
         br.b    _50
_40:    or.l    r4,r4
         beq.b   _60
         move.l  r4,r5

_60:    jsr.l   (GetConsoleWindow)

         move.l  r5,-(sp)
         move.l  r0,-(sp)
         jsr.l   (ShowWindow)

         moveq.l #0,-(sp)
         jsr.l   (ExitProcess)   ; exit program

[toc] | [prev] | [next] | [standalone]

#1538

Herbert Kleebauer wrote:

>> I post the usage of showwin.exe

Thanks for the showwin.{bat,exe} which ran the FOSS {adb,scrcpy} commands
omitting the scrcpy console (for efficiency and a clean user environment).
 <https://i.postimg.cc/XqZsmVFM/scrcpy14.jpg> AppPath & shortcut TARGET

The only minor issue I had setting it up with shortcuts and AppPaths was
that you can't "directly" pin a batch file to the taskbar by default.

A. You can _not_ pin this shortcut to the taskbar
   TARGET=C:\app\editor\android\scrcpy\showwin.bat

B. But you _can_ pin this shortcut to the taskbar
   TARGET=%comspec% /c C:\app\editor\android\scrcpy\showwin.bat

Hence I added a "%comspec% /c% and _then_ I could pin the shortcut to the
batch file to the taskbar (and, once it's pinned, you can change it back).

Here is an illustration of the necessary change to pin the shortcut:
 <https://i.postimg.cc/g2yNftw0/scrcpy15.jpg> Trick to pin batch shortcut

[toc] | [prev] | [next] | [standalone]

#1653

Woo hoo!

*IMPORTANT UPDATE* to work around the total absence of 'Ctrl-Z,bg'
 <https://i.postimg.cc/zfLp8b2v/adb22.jpg> New 'Ctrl+Z,bg' workaround

It took me days (elapsed time) to figure out this latest workaround 
to the complete and utter total lack of 'Ctrl+Z,bg' in Windows.

Yet, the final solution turns out to be incredibly simple.
If you know a few of the tricks, that is.

This lack of 'Ctrl+Z,bg' is a horrible deficiency of Windows indeed.
Luckily, with your help, we created a USB 'Ctrl+Z,bg' workaround.

And, after testing for days, *we have a Wi-Fi 'Ctrl+Z,bg' workaround.*

This new 'Ctrl+Z,bg' workaround can now be added to the existing
'Ctrl+Z,bg' workaround batch script kindly authored by Herbert.

It need only be a variable, e.g., %GET-RANDOM-PORT-ASSIGNMENT%

As you may recall, the 'Ctrl+Z,bg' workaround script Herbert kindly
proposed was to solve the lack of 'Ctrl+Z,bg' in Windows given 
conditions of an initial USB connection.

That initial USB connection only needed a _static_ port address.

So the previous 'Ctrl+Z,bg' workaround script worked fine as that 
previous 'Ctrl+Z,bg' workaround script didn't need to query Android 
for the port address.

The problem that arose in Android 11+ is the addition of Wireless 
debugging which necessitated the 'Ctrl-Z,bg' workaround batch script 
now knowing, a priori, what that randomly assigned wireless debugging
IP address is.

But how?
Specifically, how do you query Android WITHOUT first establishing
a connection to it (where that connection _requires_ the random port!).

Seemingly that's impossible, right?
Ah, but it's not impossible.

It took me a few days (elapsed time) to figure out how to query Android 
from Windows to _obtain_, a priori, that randomly assigned IP address!

Luckily I found two Windows commands which will obtain that random port:
 C:\> netstat -ano -p tcp | findstr "192.168.1.10"
 C:\> adb mdns services

Below is a log file reproducing the steps in only a minute or two.
 <https://i.postimg.cc/zfLp8b2v/adb22.jpg> New 'Ctrl+Z,bg' workaround
----------------------
Log file for this image: <https://i.postimg.cc/zfLp8b2v/adb22.jpg> 
C:\app\editor\android\scrcpy>netstat -ano -p tcp | findstr "192.168.1.10"

C:\app\editor\android\scrcpy>adb shell "ifconfig|grep -A 1 wlan0|tail -n 1|cut -f2 -d:|cut -f1 -d' '"
* daemon not running; starting now at tcp:5037
* daemon started successfully
adb.exe: no devices/emulators found

C:\app\editor\android\scrcpy>adb devices
List of devices attached


C:\app\editor\android\scrcpy>adb mdns services
List of discovered mdns services


C:\app\editor\android\scrcpy>On Android, turn wi-fi on & connect to the LAN (wait a minute or two)

C:\app\editor\android\scrcpy>netstat -ano -p tcp | findstr "192.168.1.10"

C:\app\editor\android\scrcpy>adb shell "ifconfig|grep -A 1 wlan0|tail -n 1|cut -f2 -d:|cut -f1 -d' '"
adb.exe: no devices/emulators found

C:\app\editor\android\scrcpy>adb devices
List of devices attached


C:\app\editor\android\scrcpy>adb mdns services
List of discovered mdns services


C:\app\editor\android\scrcpy>Now turn on Developer options, Wireless debugging & accept the "Allow" (wait 2 min)

C:\app\editor\android\scrcpy>Note that the phone knows the address & port of 192.168.1.10:36999 (not the PC)

C:\app\editor\android\scrcpy>When the phone beeps with "Wireless debugging connected", you're ready

C:\app\editor\android\scrcpy>netstat -ano -p tcp | findstr "192.168.1.10"
  TCP    192.168.1.27:49765     192.168.1.10:36999     ESTABLISHED     3208

C:\app\editor\android\scrcpy>Bingo! The PC now knows the Wireless debugging IP address & random assigned port!

C:\app\editor\android\scrcpy>adb shell "ifconfig|grep -A 1 wlan0|tail -n 1|cut -f2 -d:|cut -f1 -d' '"
192.168.1.10

C:\app\editor\android\scrcpy>Windows adb knows only the IP address (but not the randomly assigned wireless port) :(

C:\app\editor\android\scrcpy>adb devices
List of devices attached
adb-ABCEFGHIJKL-123456._adb-tls-connect._tcp.   device


C:\app\editor\android\scrcpy>adb mdns services
List of discovered mdns services
adb-ABCEFGHIJKL-123456._adb-tls-connect._tcp.  192.168.1.10:36999


C:\app\editor\android\scrcpy>Ah. Nice. So Windows adb DOES know the IP address & randomly assigned wireless debug port

C:\app\editor\android\scrcpy>scrcpy.exe
scrcpy 1.24 <https://github.com/Genymobile/scrcpy>
C:\app\editor\android\scrcpy\scrcpy-server: 1 file pushed, 0 skipped. 0.8 MB/s (41159 bytes in 0.051s)
[server] INFO: Device: samsung SM-A326U (Android 12)
INFO: Renderer: direct3d
INFO: Initial texture: 720x1600

At this point you would die for a "control-Z bg" command sequence.
If that 'Ctrl+Z,bg' existed on Windows, this thread wouldn't be needed.
But alas, Windows completely lacks such a 'Ctrl+Z,bg' luxury.
Hence the need for a 'Ctrl+Z,bg' workaround batch script.

If 'Ctrl+Z,bg' existed on Windows, we would never have this problem
of querying Android from Windows to obtain the Wireless-debugging 
port random assignment (because scrcpy console does NOT need it!).

But if we want to eliminate the scrcpy console, then we need to 
find a workaround to the fact that Windows completely lacks a
basic 'Ctrl+Z,bg' functionality. <=== this is the problem!

Since 'Ctrl+Z,bg' does NOT exist on the PC, we need to tell 
the 'Ctrl+Z,bg' workaround batch script what that randomly assigned
port is set to on Android WITHOUT looking at Android.

The 'Ctrl+Z,bg' workaround script must figure it out on its own!
Hence you must figure out the random port assignment from the PC.

Notice scrcpy with the console does NOT need to know this port.
It figures it out on its own.

So it's only the 'Ctrl+Z,bg' workaround script that NEEDS this port.
All we need now is to ADD that new 'Ctrl+Z,bg' variable to the script!

In summary, the old USB 'Ctrl+Z,bg' workaround, which expects a static port, only needs to have added a new 'Ctrl+Z,bg' variable, 
e.g., %GET-RANDOM-PORT-ASSIGNMENT%

[toc] | [prev] | [next] | [standalone]

#1533

On 23.04.2022 17:04, Herbert Kleebauer wrote:
> @echo off
> certutil -f -decode %~f0 showwin.exe>nul
> 
> cd /d "c:\app\editor\android\scrcpy"
> adb connect 192.168.0.2:5555


You have to do the cd before creating the exe

 > @echo off

 > cd /d "c:\app\editor\android\scrcpy"
 > certutil -f -decode %~f0 showwin.exe>nul
 >
 > adb connect 192.168.0.2:5555

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | alt.comp.microsoft.windows

csiph-web