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

Groups > alt.comp.os.windows-10 > #183090 > unrolled thread

Re: what is the fastest command line copy?

Back to article view | Back to alt.comp.os.windows-10

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: what is the fastest command line copy? Dual Boot Windows <invalid@invalid.invalid> - 2025-03-31 02:12 +0100
    Re: what is the fastest command line copy? Steve Hayes <hayesstw@telkomsa.net> - 2025-03-31 04:43 +0200
      Re: what is the fastest command line copy? Paul <nospam@needed.invalid> - 2025-03-31 00:47 -0400
        Re: what is the fastest command line copy? Steve Hayes <hayesstw@telkomsa.net> - 2025-03-31 11:06 +0200
        Re: what is the fastest command line copy? Stan Brown <the_stan_brown@fastmail.fm> - 2025-03-31 12:10 -0700
        Re: what is the fastest command line copy? "Jonathan N. Little" <lws4art@gmail.com> - 2025-04-01 18:56 -0400
      Re: what is the fastest command line copy? Newyana2 <newyana@invalid.nospam> - 2025-03-31 08:21 -0400
        Re: what is the fastest command line copy? "R.Wieser" <address@is.invalid> - 2025-03-31 15:47 +0200
          Re: what is the fastest command line copy? Newyana2 <newyana@invalid.nospam> - 2025-03-31 10:54 -0400
            Re: what is the fastest command line copy? Andy Burns <usenet@andyburns.uk> - 2025-03-31 15:59 +0100
            Re: what is the fastest command line copy? "R.Wieser" <address@is.invalid> - 2025-03-31 17:32 +0200
            Re: what is the fastest command line copy? Steve Hayes <hayesstw@telkomsa.net> - 2025-04-01 07:00 +0200
              Re: what is the fastest command line copy? "R.Wieser" <address@is.invalid> - 2025-04-01 09:11 +0200
              Re: what is the fastest command line copy? Paul <nospam@needed.invalid> - 2025-04-01 03:44 -0400
              Re: what is the fastest command line copy? Newyana2 <newyana@invalid.nospam> - 2025-04-01 09:26 -0400
                Re: what is the fastest command line copy? Steve Hayes <hayesstw@telkomsa.net> - 2025-04-02 08:50 +0200
                  Re: what is the fastest command line copy? Paul <nospam@needed.invalid> - 2025-04-02 04:15 -0400
                    Re: what is the fastest command line copy? "R.Wieser" <address@is.invalid> - 2025-04-02 10:35 +0200
                      Re: what is the fastest command line copy? Paul <nospam@needed.invalid> - 2025-04-02 05:54 -0400
                        Re: what is the fastest command line copy? "R.Wieser" <address@is.invalid> - 2025-04-02 16:15 +0200
                          Re: what is the fastest command line copy? Paul <nospam@needed.invalid> - 2025-04-02 11:40 -0400
                            Re: what is the fastest command line copy? "R.Wieser" <address@is.invalid> - 2025-04-02 18:13 +0200
                              Re: what is the fastest command line copy? Paul <nospam@needed.invalid> - 2025-04-02 12:41 -0400
                                Re: what is the fastest command line copy? "R.Wieser" <address@is.invalid> - 2025-04-02 20:27 +0200
                                  Re: what is the fastest command line copy? Paul <nospam@needed.invalid> - 2025-04-03 03:22 -0400
                                    Re: what is the fastest command line copy? "R.Wieser" <address@is.invalid> - 2025-04-03 13:10 +0200
                      Re: what is the fastest command line copy? Newyana2 <newyana@invalid.nospam> - 2025-04-02 07:57 -0400
                        Re: what is the fastest command line copy? "R.Wieser" <address@is.invalid> - 2025-04-02 16:19 +0200
                          Re: what is the fastest command line copy? Newyana2 <newyana@invalid.nospam> - 2025-04-02 11:04 -0400
                            Re: what is the fastest command line copy? Paul <nospam@needed.invalid> - 2025-04-02 12:04 -0400
                            Re: what is the fastest command line copy? "R.Wieser" <address@is.invalid> - 2025-04-02 18:06 +0200
                    Re: what is the fastest command line copy? Frank Slootweg <this@ddress.is.invalid> - 2025-04-02 12:41 +0000
                      Re: what is the fastest command line copy? Paul <nospam@needed.invalid> - 2025-04-02 12:15 -0400
                        Re: what is the fastest command line copy? Frank Slootweg <this@ddress.is.invalid> - 2025-04-02 17:36 +0000
                    Re: what is the fastest command line copy? Stan Brown <the_stan_brown@fastmail.fm> - 2025-04-02 10:50 -0700
                    Re: what is the fastest command line copy? Steve Hayes <hayesstw@telkomsa.net> - 2025-04-03 05:24 +0200
                      Re: what is the fastest command line copy? Democrat <Democrat@invalid.invalid> - 2025-04-03 06:00 +0000
                        Re: what is the fastest command line copy? "R.Wieser" <address@is.invalid> - 2025-04-03 08:39 +0200
                        Re: what is the fastest command line copy? Steve Hayes <hayesstw@telkomsa.net> - 2025-04-03 15:55 +0200
                          Re: what is the fastest command line copy? Frank Slootweg <this@ddress.is.invalid> - 2025-04-03 15:06 +0000
                            Re: what is the fastest command line copy? Steve Hayes <hayesstw@telkomsa.net> - 2025-04-04 13:55 +0200
                              Re: what is the fastest command line copy? Frank Slootweg <this@ddress.is.invalid> - 2025-04-04 12:11 +0000
                                Re: what is the fastest command line copy? Don_from_AZ <djatechNOSPAM@comcast.net.invalid> - 2025-04-04 10:32 -0700
                                Re: what is the fastest command line copy? Steve Hayes <hayesstw@telkomsa.net> - 2025-04-05 05:20 +0200
                                  Re: what is the fastest command line copy? T <T@invalid.invalid> - 2025-04-05 00:44 -0700
                                  Re: what is the fastest command line copy? Daniel70 <daniel47@eternal-september.org> - 2025-04-06 20:20 +1000
                                    Re: what is the fastest command line copy? "Kerr-Mudd, John" <admin@127.0.0.1> - 2025-04-06 21:15 +0100
                              Re: what is the fastest command line copy? Newyana2 <newyana@invalid.nospam> - 2025-04-04 08:49 -0400
                                Re: what is the fastest command line copy? Steve Hayes <hayesstw@telkomsa.net> - 2025-04-05 05:29 +0200
                                  Re: what is the fastest command line copy? Newyana2 <newyana@invalid.nospam> - 2025-04-05 08:26 -0400
                                Re: what is the fastest command line copy? Paul <nospam@needed.invalid> - 2025-04-05 00:37 -0400
                                  Re: what is the fastest command line copy? Newyana2 <newyana@invalid.nospam> - 2025-04-05 08:18 -0400
                          Re: what is the fastest command line copy? Char Jackson <none@none.invalid> - 2025-04-03 11:00 -0500
                  Re: what is the fastest command line copy? Newyana2 <newyana@invalid.nospam> - 2025-04-02 07:53 -0400
                    Re: what is the fastest command line copy? "R.Wieser" <address@is.invalid> - 2025-04-02 16:26 +0200
                      Re: what is the fastest command line copy? Newyana2 <newyana@invalid.nospam> - 2025-04-02 11:03 -0400
                        Re: what is the fastest command line copy? "R.Wieser" <address@is.invalid> - 2025-04-02 18:04 +0200
                        Re: what is the fastest command line copy? Paul <nospam@needed.invalid> - 2025-04-02 12:36 -0400
                          Re: what is the fastest command line copy? Newyana2 <newyana@invalid.nospam> - 2025-04-02 13:07 -0400
                            Re: what is the fastest command line copy? Paul <nospam@needed.invalid> - 2025-04-03 04:14 -0400
                              Re: what is the fastest command line copy? Newyana2 <newyana@invalid.nospam> - 2025-04-03 08:40 -0400
                  Re: what is the fastest command line copy? Stan Brown <the_stan_brown@fastmail.fm> - 2025-04-02 10:43 -0700
                    Re: what is the fastest command line copy? Char Jackson <none@none.invalid> - 2025-04-02 18:59 -0500
                  Re: what is the fastest command line copy? Stan Brown <the_stan_brown@fastmail.fm> - 2025-04-02 11:11 -0700
          Re: what is the fastest command line copy? knuttle <keith_nuttle@yahoo.com> - 2025-03-31 10:59 -0400
            Re: what is the fastest command line copy? "R.Wieser" <address@is.invalid> - 2025-03-31 17:26 +0200
              Re: what is the fastest command line copy? Newyana2 <newyana@invalid.nospam> - 2025-03-31 13:05 -0400
                Re: what is the fastest command line copy? "R.Wieser" <address@is.invalid> - 2025-03-31 20:18 +0200
                  Re: what is the fastest command line copy? Newyana2 <newyana@invalid.nospam> - 2025-03-31 14:43 -0400
      Re: what is the fastest command line copy? Stan Brown <the_stan_brown@fastmail.fm> - 2025-03-31 13:40 -0700
    Re: what is the fastest command line copy? T <T@invalid.invalid> - 2025-03-30 23:03 -0700
    Re: what is the fastest command line copy? T <T@invalid.invalid> - 2025-03-30 23:43 -0700
    Re: what is the fastest command line copy? T <T@invalid.invalid> - 2025-04-01 02:01 -0700

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#183232

On 3 Apr 2025 15:06:34 GMT, Frank Slootweg <this@ddress.is.invalid>
wrote:

>Steve Hayes <hayesstw@telkomsa.net> wrote:
>[...]
>
>> * if applications can be called "apps" surely utilities can be called
>> "utes"?
>
>  Utes are big things and apps are normally small things. But you can
>call anything, anything you like, so 'utes' it is! :-)
>
><https://www.google.com/search?q=define%3A+ute>

That's in AusE. We call those "bakkies" in SAfE. 

But its still short for "utilities" (the U in SUV) so you can just as
easily use the abbreviation for utility programs on your computer. 



-- 
Steve Hayes from Tshwane, South Africa
Web:  http://www.khanya.org.za/stevesig.htm
Blog: http://khanya.wordpress.com
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk

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

#183233

Steve Hayes <hayesstw@telkomsa.net> wrote:
> On 3 Apr 2025 15:06:34 GMT, Frank Slootweg <this@ddress.is.invalid>
> wrote:
> 
> >Steve Hayes <hayesstw@telkomsa.net> wrote:
> >[...]
> >
> >> * if applications can be called "apps" surely utilities can be called
> >> "utes"?
> >
> >  Utes are big things and apps are normally small things. But you can
> >call anything, anything you like, so 'utes' it is! :-)
> >
> ><https://www.google.com/search?q=define%3A+ute>
> 
> That's in AusE. We call those "bakkies" in SAfE. 

  For this Dutchie, "bakkies" is perfectly natural.

> But its still short for "utilities" (the U in SUV) so you can just as
> easily use the abbreviation for utility programs on your computer. 

  Yes, in future, in the off chance we get stuck in some kind of
constructive discussion, let's throw in some comments about 'utes'.
That'll teach them! :-)

  My ute can beat up your ute!

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

#183235

Frank Slootweg <this@ddress.is.invalid> writes:

> Steve Hayes <hayesstw@telkomsa.net> wrote:
>> On 3 Apr 2025 15:06:34 GMT, Frank Slootweg <this@ddress.is.invalid>
>> wrote:
>> 
>> >Steve Hayes <hayesstw@telkomsa.net> wrote:
>> >[...]
>> >
>> >> * if applications can be called "apps" surely utilities can be called
>> >> "utes"?
>> >
>> >  Utes are big things and apps are normally small things. But you can
>> >call anything, anything you like, so 'utes' it is! :-)
>> >
>> ><https://www.google.com/search?q=define%3A+ute>
>> 
>> That's in AusE. We call those "bakkies" in SAfE. 
>
>   For this Dutchie, "bakkies" is perfectly natural.
>
>> But its still short for "utilities" (the U in SUV) so you can just as
>> easily use the abbreviation for utility programs on your computer. 
>
>   Yes, in future, in the off chance we get stuck in some kind of
> constructive discussion, let's throw in some comments about 'utes'.
> That'll teach them! :-)
>
>   My ute can beat up your ute!
Just to muddy the waters,

  "Utes" are an Indigenous people of the Great Basin and Colorado
  Plateau in present-day Utah, western Colorado, and northern New
  Mexico.[7][3] Historically, their territory also included parts of
  Wyoming, eastern Nevada, and Arizona.

  https://en.wikipedia.org/wiki/Ute_people
-- 
-Don_from_AZ-

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

#183246

On 4 Apr 2025 12:11:59 GMT, Frank Slootweg <this@ddress.is.invalid>
wrote:

>Steve Hayes <hayesstw@telkomsa.net> wrote:
>> But its still short for "utilities" (the U in SUV) so you can just as
>> easily use the abbreviation for utility programs on your computer. 
>
>  Yes, in future, in the off chance we get stuck in some kind of
>constructive discussion, let's throw in some comments about 'utes'.
>That'll teach them! :-)
>
>  My ute can beat up your ute!

It's part of the fight-back against the trend to call utilities
"apps". 


-- 
Steve Hayes from Tshwane, South Africa
Web:  http://www.khanya.org.za/stevesig.htm
Blog: http://khanya.wordpress.com
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk

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

#183252

On 4/4/25 8:20 PM, Steve Hayes wrote:
> On 4 Apr 2025 12:11:59 GMT, Frank Slootweg <this@ddress.is.invalid>
> wrote:
> 
>> Steve Hayes <hayesstw@telkomsa.net> wrote:
>>> But its still short for "utilities" (the U in SUV) so you can just as
>>> easily use the abbreviation for utility programs on your computer.
>>
>>   Yes, in future, in the off chance we get stuck in some kind of
>> constructive discussion, let's throw in some comments about 'utes'.
>> That'll teach them! :-)
>>
>>   My ute can beat up your ute!
> 
> It's part of the fight-back against the trend to call utilities
> "apps".


One of my programs is 13885 lines long.  Some folk still
call it a "script" because it is written in Raku (Perl 6)

Five lines is a script.  13885 line is a program.  I do
not care what language it is written in,

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

#183272

On 5/04/2025 2:20 pm, Steve Hayes wrote:
> On 4 Apr 2025 12:11:59 GMT, Frank Slootweg <this@ddress.is.invalid>
> wrote:
> 
>> Steve Hayes <hayesstw@telkomsa.net> wrote:
>>> But its still short for "utilities" (the U in SUV) so you can just as
>>> easily use the abbreviation for utility programs on your computer.
>>
>>   Yes, in future, in the off chance we get stuck in some kind of
>> constructive discussion, let's throw in some comments about 'utes'.
>> That'll teach them! :-)
>>
>>   My ute can beat up your ute!
> 
> It's part of the fight-back against the trend to call utilities
> "apps".
> 
I thought 'Utilities' included Gas, Water and Electricity! ;-P
-- 
Daniel70

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

#183286

On Sun, 6 Apr 2025 20:20:09 +1000
Daniel70 <daniel47@eternal-september.org> wrote:

> On 5/04/2025 2:20 pm, Steve Hayes wrote:
> > On 4 Apr 2025 12:11:59 GMT, Frank Slootweg <this@ddress.is.invalid>
> > wrote:
> > 
> >> Steve Hayes <hayesstw@telkomsa.net> wrote:
> >>> But its still short for "utilities" (the U in SUV) so you can just as
> >>> easily use the abbreviation for utility programs on your computer.
> >>
> >>   Yes, in future, in the off chance we get stuck in some kind of
> >> constructive discussion, let's throw in some comments about 'utes'.
> >> That'll teach them! :-)
> >>
> >>   My ute can beat up your ute!
> > 
> > It's part of the fight-back against the trend to call utilities
> > "apps".
> > 
> I thought 'Utilities' included Gas, Water and Electricity! ;-P

I prefer the Stations, at least in the early part. Oh -  this isn't the
Monopoly strategy forum.


-- 
Bah, and indeed Humbug.

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

#183234

On 4/4/2025 7:55 AM, Steve Hayes wrote:
> 
> But its still short for "utilities" (the U in SUV) so you can just as
> easily use the abbreviation for utility programs on your computer.
> 

   I've always disliked "apps", too. In my memory it originates
with Apple ads: "There's an app for that." Like all things
Apple, it's a bit too cute, like talking to a 12 year old girl.
But now that the term is established, at least it's a way to
distinguish compiled Win32 software executables from
Metro/WinRT/UWP applets.

   Microsoft have a long history of butchering the English
language with tasteless marketing. WinME was supposed
to be pronounced, and written, "Windows Me". But they
couldn't quite swallow their own sleaze, so the logo was a
lowercase e, but as high as the M. Then there was
"solutions" as a substitute for "projects" -- marketing the
software before it's even written.

My favorite all-time gibberish: "Leveraging solutions across
the enterprise". (Translation: Using software at work.)

My favorite example of shooting themselves in the foot:
"Hailstorm" as a name for a set of online services.

Their latest obnoxious gimmick is "experiences":

"Windows also provides experiences that connect to the
  internet to provide additional capabilities. These
connected experiences can help you in various ways."

   It's an interesting choice. The term seems to assume
that Windows customers tend to feel that they're "missing
the boat" in their life. Numb. So all Microsoft products are
called "experiences". Not only can you write a letter with
Office365. It will enrich your life so that you don't feel like
such a loser. Always dreamed of climbing Everest or touring
the national parks, but you never got around to it? Not to
worry. You can use Outlook, which is just as good. "You
can have a rich, fulfilling life, for only 15 bucks a month."

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

#183247

On Fri, 4 Apr 2025 08:49:02 -0400, Newyana2 <newyana@invalid.nospam>
wrote:

>On 4/4/2025 7:55 AM, Steve Hayes wrote:
>> 
>> But its still short for "utilities" (the U in SUV) so you can just as
>> easily use the abbreviation for utility programs on your computer.
>> 
>
>   I've always disliked "apps", too. In my memory it originates
>with Apple ads: "There's an app for that." Like all things
>Apple, it's a bit too cute, like talking to a 12 year old girl.
>But now that the term is established, at least it's a way to
>distinguish compiled Win32 software executables from
>Metro/WinRT/UWP applets.
>
>   Microsoft have a long history of butchering the English
>language with tasteless marketing. WinME was supposed
>to be pronounced, and written, "Windows Me". But they
>couldn't quite swallow their own sleaze, so the logo was a
>lowercase e, but as high as the M. Then there was
>"solutions" as a substitute for "projects" -- marketing the
>software before it's even written.

Yes, that one has always annoyed me. Advertising "solutions" is
meaningless of you don't know what the problem is. 


>My favorite all-time gibberish: "Leveraging solutions across
>the enterprise". (Translation: Using software at work.)
>
>My favorite example of shooting themselves in the foot:
>"Hailstorm" as a name for a set of online services.
>
>Their latest obnoxious gimmick is "experiences":
>
>"Windows also provides experiences that connect to the
>  internet to provide additional capabilities. These
>connected experiences can help you in various ways."
>
>   It's an interesting choice. The term seems to assume
>that Windows customers tend to feel that they're "missing
>the boat" in their life. Numb. So all Microsoft products are
>called "experiences". Not only can you write a letter with
>Office365. It will enrich your life so that you don't feel like
>such a loser. Always dreamed of climbing Everest or touring
>the national parks, but you never got around to it? Not to
>worry. You can use Outlook, which is just as good. "You
>can have a rich, fulfilling life, for only 15 bucks a month."

And then there's UX (User Experience), which usually means that
programmers and web designers are obsessed with bells and whistles and
ignore pistons and cylinders. So the main user experience is
frustration, because the damned thing doesn't actually DO anything,
but just sits on the screen preening itself.

 



And my main user experience is frustration
-- 
Steve Hayes from Tshwane, South Africa
Web:  http://www.khanya.org.za/stevesig.htm
Blog: http://khanya.wordpress.com
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk

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

#183260

On 4/4/2025 11:29 PM, Steve Hayes wrote:

> And then there's UX (User Experience), which usually means that
> programmers and web designers are obsessed with bells and whistles and
> ignore pistons and cylinders. So the main user experience is
> frustration, because the damned thing doesn't actually DO anything,
> but just sits on the screen preening itself.
> 

    That's one I hadn't thought of. I've been only vaguely aware
of "UX". But you're right. The idea of interface design as marketing
scam is so widespread that they wanted an acronym for it. Design
used to mean thoughtful planning to put buttons and menus in
intuitive locations. Now it's more likely to mean steering the
enduser toward a particular entertainment usage.

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

#183250

On Fri, 4/4/2025 8:49 AM, Newyana2 wrote:

> 
>   It's an interesting choice. The term seems to assume
> that Windows customers tend to feel that they're "missing
> the boat" in their life. Numb. So all Microsoft products are
> called "experiences". Not only can you write a letter with
> Office365. It will enrich your life so that you don't feel like
> such a loser. Always dreamed of climbing Everest or touring
> the national parks, but you never got around to it? Not to
> worry. You can use Outlook, which is just as good. "You
> can have a rich, fulfilling life, for only 15 bucks a month."
> 

Your computer is about to call you Emily.

   https://store-images.s-microsoft.com/image/apps.53040.13623743226081137.36b6be7c-6a3b-4414-b1d9-f1b3eb178dea.1e9fda02-60ba-4925-a841-ab921b2841fd?h=768

Without using Recall, CoPilot has another way of watching your desktop.
And your camera input, if you connect a camera to the PC.

   https://www.tomshardware.com/software/windows/microsoft-celebrates-its-50th-anniversary-by-letting-copilot-see-what-you-see

  Paul

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

#183259

On 4/5/2025 12:37 AM, Paul wrote:

> Your computer is about to call you Emily.
> 
>     https://store-images.s-microsoft.com/image/apps.53040.13623743226081137.36b6be7c-6a3b-4414-b1d9-f1b3eb178dea.1e9fda02-60ba-4925-a841-ab921b2841fd?h=768
> 
> Without using Recall, CoPilot has another way of watching your desktop.
> And your camera input, if you connect a camera to the PC.
> 
>     https://www.tomshardware.com/software/windows/microsoft-celebrates-its-50th-anniversary-by-letting-copilot-see-what-you-see
> 

    I expect that a lot of people will like that. Most people
loathe managing their computer. I have no Copilots and
no cameras. But if they come back with that sexy Cortana
babe -- the blue one in the tight onesie with glowing
transistors on her thighs, and the mindless enthusiasm in her
eyes that only robots can offer -- then we can talk.

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

#183229

On Thu, 03 Apr 2025 15:55:55 +0200, Steve Hayes <hayesstw@telkomsa.net>
wrote:

>The error I referred to appears to be in one of the utes* called by
>the batch file. 
>
>* if applications can be called "apps" surely utilities can be called
>"utes"?

Utes are the two guys who were falsely accused in My Cousin Vinny.

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

#183168

On 4/2/2025 2:50 AM, Steve Hayes wrote:
>> The whole point of scripting for me is
>> so that I only have to do something once. Next time I only have
>> to double-click or drag-drop.
> 
> I'm not sure what you're saying here.
> 
> I have four batch files:
> 
> dsk2flsh.bat
> flsh2lap.bat
> lap2flsh.bat
> flsh2dsk.bat
> 
> I only have to remember the exact syntax when I make the batch files,
> and after that I I have to remember is the name of the batch file.
> 

   Yes. That's one way of operating. As you said, that's
technically a way of scripting, inasmuch as it's interpreted
text. I was comparing scripting in the sense of WSH to
typing commands in a console window. As I said at the start,
life is too short for commandline. There's a fetish aspect to
typing into console windows that oldtimers like and young
people regard as a hazing process. It's much worse on Linux.
And it's not unusual that I get stuck using that method.
Every time I want to update my Raspberry Pi I have to find
that little piece of paper I saved that records the requisite
incantations. That's simply a case of programmers not finishing
the job. After 30 years of GUI we shouldn't ever HAVE TO open
a console window.

    Much of the reason we do is not even programmer
laziness. It's more oldtimer stubbornness. Awhile back I was
trying out Xubuntu and couldn't adjust the clock. Odd. I finally
found a discussion online where the man who coded the clock said
that he specifically didn't add GUI settings because he finds
console window easier. But it's a GUI system! He's like a kid in
a self-driving car who likes to have a clutch pedal just so that he
can feel like he's a cowboy. And he wants everyone to know
that he's a cowboy, who's so tough that he's even played video
games of wrestling a grizzly bear. So he's not going to let anyone
else adjust the clock via GUI, either.

    I have a file that I keep on hand to remind me of various DISM
commands I need. Could I put those in a PS script? Maybe. But I
usually just need one. In fact I have a VBS script to clean TEMP
files, then I pop up a messagebox at the end that says,
"Also clean up winsxs with this command:
Dism.exe /online /Cleanup-Image /StartComponentCleanup /ResetBase"

   That way I don't have to go looking up the command. I can just copy
and paste from the messagebox window. But why
isn't there a "Cleanup winsxs" button in System -> Advanced Options
-> Advanced -> Advanced -> Advanced -> Advanced?

   If you're only using pre-written BAT files then that's different.
So, then, what's the difference between that and WSH?

    The difference would be that
BAT files are a primitive approach that WSH was designed
to replace... 30 years ago. Very limited GUI options. Very limited
options for multiple contexts and concurrent operations. No
classes, subroutines, etc. No way to exploit the vast COM
libraries on Windows. Mostly just one-liner calls to
external applets that can do something for you. Your 4 BAT
files only provide options for 4 exact copy operations from A
to B, B to A, A to C, C to A. In other words, it's a 30-year-old
paradigm intended for console screens. My drag-drop script
defines the files to move through simple drag-drop. The options
are unlimited. GUI. Post-1995.

    DOS/BAT is basically one-liner calls that ignore
the vast programming options that Microsoft developed since
1995. It's designed to mimic the DOS command screen that
oldtimers know from pre-GUI days.

   DOS/BAT, and now PS, work well for people who started
with DOS and don't need anything else. As I said, scripting
is not for everyone. I was just just pointing out, for anyone
who's curious, that there are options to use more customized
approaches that are not just complicated incantation one-liners
strung together.

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

#183174

Newyana2,

> As I said at the start, life is too short for commandline.

How do you keep tabs on the progress of your scripts ?

Personally I like seeing a long-running script telling me what its currently 
doing.  And the easiest way is to run the (VB)Script in a console so that 
you can see what its outputting - without having to press the "OK" button on 
everything it outputs.

Though that doesn't mean you can't start them by double-clicking or dropping 
files/folders onto them.

Regards,
Rudy Wieser

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

#183175

On 4/2/2025 10:26 AM, R.Wieser wrote:
> Newyana2,
> 
>> As I said at the start, life is too short for commandline.
> 
> How do you keep tabs on the progress of your scripts ?
> 
> Personally I like seeing a long-running script telling me what its currently
> doing.  And the easiest way is to run the (VB)Script in a console so that
> you can see what its outputting - without having to press the "OK" button on
> everything it outputs.
> 
> Though that doesn't mean you can't start them by double-clicking or dropping
> files/folders onto them.
> 
      I've never used the console output. Generally I just
use error trapping and show a msgbox at the end: "Done."
For instance, if a script expects a dropped file then if there
is no drop then I'll show an inputbox or a message.

   For scripts that I'm going to use more than once I try
to make them robust in that way. I check whether files
exist, I confirm math operations... then at the end I add
On Error Resume Next. So I don't really need to monitor
anything. That's done when writing the script. Much of the
point is to be able to just double-click or drop and have
the details taken care of. It shouldn't need console output.

   For more complicated things I'll do as Paul described, using
numbered errors. But that's mostly in compiled software,
where I'm using 3rd-party libraries that might return errors,
which I might want to be able to troubleshoot. But even then,
there shouldn't be errors or weaknesses in my own code. If
I put up an inputbox for a file path, that path should exist.
If I put up an inputbox for a number, that should pass
IsNumeric.

   If I want a report then I put that in the script. for instance,
my file copy script generates a text file listing what was
copied.

   What kinds of things do you do that need console reporting
mid-script?

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

#183179

Newyana2,

> Generally I just use error trapping and show a msgbox at the end: "Done."

The "error trapping" goes without saying.

As for the latter ?  I've got short-running scripts I do not even bother to 
let them tell they are finished.

But when its a longer-running script (or one making a lot of changes) than I 
have the need to see it progressing.  Yes, my earlier long-running scripts 
finished like yours, with a msgbox.

But have you never noticed that time slows to a crawl when you are waiting 
for something to happen but have no idea how long it will take ?   I rather 
see paint dry.

The easiest "progres indicator" is to output to a console window.

> If I want a report then I put that in the script. for instance,
> my file copy script generates a text file listing what was
> copied.

Same here.  What was updated, was new, or could not be copied for whatever 
reason.

Regards,
Rudy Wieser

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

#183183

On Wed, 4/2/2025 11:03 AM, Newyana2 wrote:

> 
>   What kinds of things do you do that need console reporting
> mid-script?
> 

For long running scripts, you could use a bit of progress indication.
What percent done.

In the old days, this was the entering of dots on the screen.
And my favorites were always the programming efforts where
the "dots went off the side of the screen". Such attention
to detail :-) The people doing that, didn't know the terminal
in that case, didn't have autowrap. (Yes, there were actually
terminal emulators *that* crude.)

In my Robocopy command, you can see I like to use the output
as a form of progress indication, as well as making a
permanent log.

robocopy Y:\ F:\ /mir /COPYALL /dcopy:t /XJ /r:3 /w:2 /zb /np /tee /v /log:robocopy_y_to_f.log

   /tee                       # Log to screen, log to file
   /v                         # Verbose
   /log:robocopy_y_to_f.log   # Each run gets a logfile (for unique src:dest pairs)

You don't actually look at that. The idea is, you open a Terminal, paste
the command, then... watch that the run has started OK. Iconify. Open
the Terminal after ten minutes, inspect and see it's still on target.
Iconify. You can use Task Manager or the disk LED, to identify the
command is thoroughly done.

  Paul

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

#183186

On 4/2/2025 12:36 PM, Paul wrote:
> On Wed, 4/2/2025 11:03 AM, Newyana2 wrote:
> 
>>
>>    What kinds of things do you do that need console reporting
>> mid-script?
>>
> 
> For long running scripts, you could use a bit of progress indication.
> What percent done.
> 
> In the old days, this was the entering of dots on the screen.
> And my favorites were always the programming efforts where
> the "dots went off the side of the screen". Such attention
> to detail :-) The people doing that, didn't know the terminal
> in that case, didn't have autowrap. (Yes, there were actually
> terminal emulators *that* crude.)
> 
> In my Robocopy command, you can see I like to use the output
> as a form of progress indication, as well as making a
> permanent log.
> 
> robocopy Y:\ F:\ /mir /COPYALL /dcopy:t /XJ /r:3 /w:2 /zb /np /tee /v /log:robocopy_y_to_f.log
> 
>     /tee                       # Log to screen, log to file
>     /v                         # Verbose
>     /log:robocopy_y_to_f.log   # Each run gets a logfile (for unique src:dest pairs)
> 
> You don't actually look at that. The idea is, you open a Terminal, paste
> the command, then... watch that the run has started OK. Iconify. Open
> the Terminal after ten minutes, inspect and see it's still on target.
> Iconify. You can use Task Manager or the disk LED, to identify the
> command is thoroughly done.
> 
>    Paul
> 

    I haven't really run into such situations. On rare occasions I
might have a script where I'm surprised at the slow speed. But
I just optimize as much as possible and live with it. Usually scripts
like that are one-time operations.

   I have found some surprising details about speed with VBS.
For example, with a lot of text it's much faster to put each small
string into an array and then run a Join than to keep concatenating
little strings past the point of petty cash memory reserveed by WSH.

   Another surprising difference is that if a lot of string operations
are to be done then it's good to convert it to UCase or LCase
first.

    Once I've done those kinds of optimizations, and I know the
script works, I'm happy to just let it do its work. I don't need
to see a progress bar. I could, theoretically, set up a GUI progress
bar, but even if I cared, getting accurate percentage of progress
is usually not possible.

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

#183209

On Wed, 4/2/2025 1:07 PM, Newyana2 wrote:

>    I haven't really run into such situations. On rare occasions I
> might have a script where I'm surprised at the slow speed. But
> I just optimize as much as possible and live with it. Usually scripts
> like that are one-time operations.
> 
>   I have found some surprising details about speed with VBS.
> For example, with a lot of text it's much faster to put each small
> string into an array and then run a Join than to keep concatenating
> little strings past the point of petty cash memory reserveed by WSH.
> 
>   Another surprising difference is that if a lot of string operations
> are to be done then it's good to convert it to UCase or LCase
> first.
> 
>    Once I've done those kinds of optimizations, and I know the
> script works, I'm happy to just let it do its work. I don't need
> to see a progress bar. I could, theoretically, set up a GUI progress
> bar, but even if I cared, getting accurate percentage of progress
> is usually not possible.

The OS is chock full of examples of "energy waste working up data
for progress indicators" and "indicators that were nuts".

I like the CHKDSK one that says "15 minute remaining" and one
second later, the command run is finished. Now, that's a progress
indicator.

The progress shown in Macrium is not bad, with the exception
that some operations have text telling you the transfer rate
and others, do not.

You can get rough indications of progress, using Task Manager
and adding "I/O Read Bytes" and "I/O Write Bytes" columns. If you
know a command of yours will be doing 70GB of transfers, you
can check Task Manager and "see how much work it has done",
to get some idea how much is left to do.

The performance counters on Windows, don't work for everything,
so some attempts to add instrumentation to your screen, just
aren't going to work. You can set up a perfmon.msc screen
to monitor rates. One of the tricks there, is setting the Y axis
scaling, so the results fit on the screen properly.

For disk read/write, I set the graph axis to "800000" which
is apparently 8GB/sec, so that my 2GB/sec and 3GB/sec activities
can be seen. This is my little paulcopy64.exe program, copying
a file (because it's a dumb little program). It uses fread and fwrite.
The storage device can do 6.5GB/sec, so the result indicates
my program needs work.

   [Picture]

    https://i.postimg.cc/wxncp9r5/perfmon-msc.gif

  Paul

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | alt.comp.os.windows-10

csiph-web