From: Eduardo Ochs <eduardoochs@gmail.com>
To: Tomas Hlavaty <tom@logand.com>
Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
Subject: Re: Workshop to save M$ Windows users - help needed
Date: Wed, 6 Oct 2021 01:50:00 -0300 [thread overview]
Message-ID: <CADs++6jX1awtv4WvPp4Rv+P5NTei0VH1ZFXRBq4eRYdxdPxQdw@mail.gmail.com> (raw)
In-Reply-To: <87ee90y76p.fsf@logand.com>
On Mon, 4 Oct 2021 at 15:29, Tomas Hlavaty <tom@logand.com> wrote:
>
> url-retrieve-synchronously2 had a bug
>
> this works and should dispose the nework buffer properly:
Hi Tomas (and all),
Here are some updates on the problem of using eev to install wget.exe
on Windows machines. Remember that I have good reasons to suppose the
most of the people who will participate in my workshop have never used
terminals and don't even know well enough what is a directory.
1. PowerShell
=============
Someone told me to take a look at PowerShell. Apparently it has a
built-in wget, and it is somewhat multi-platform-ish. I installed it
on my Debian box. Its main executable is called pwsh. Pwsh doesn't
run well on comint buffers - it says that the terminal is not powerful
enough. It works well on vterm and ansi-term, and so I added support
for ansi-term to eev, and I defined a function eepitch-pwsh that uses
ansi-term. I tested its built-in wget on my Debian, and it works
nice. I found a friend - who uses Windows but who has never used
terminals - who volunteered to help with the tests. It turns out that
on Windows the PowerShell executable is called powershell, not pwsh,
and it doesn't run well in an ansi-term, but it runs in comint. We
tried the scripts that I prepared and they did't work - the wget
built-in in my friend's PowerShell behaved in a way totally different
from what I expected, and when we used it to download a 400KB file it
saved to disk something that had 2MB. Then my friend found this:
https://superuser.com/questions/362152/native-alternative-to-wget-in-windows-powershell/758510#758510
And then we decided that using PowerShell would be bad karma, and we
gave up.
2. url-retrieve-synchronously
=============================
My friend was having a lot of fun executing sexps, so I decided to use
`url-retrieve-synchronously' to implement a kind of very primitive
fake wget in elisp - obs: I haven't tried your code from
https://lists.gnu.org/archive/html/help-gnu-emacs/2021-10/msg00073.html
https://lists.gnu.org/archive/html/help-gnu-emacs/2021-10/msg00075.html
yet, but I will soon! - and I got this:
http://angg.twu.net/eev-current/eev-plinks.el#find-urlretrieve
(find-wget-elisp "http://angg.twu.net/eev-current/eev-plinks.el"
"ee-very-primitive-wget0")
3. wget.exe
===========
There's a wget for Windows here:
http://gnuwin32.sourceforge.net/packages/wget.htm
http://downloads.sourceforge.net/gnuwin32/wget-1.11.4-1-bin.zip
• (eepitch-shell)
• (eepitch-kill)
• (eepitch-shell)
rm -Rv /tmp/wget/
mkdir /tmp/wget/
cd /tmp/wget/
wget http://downloads.sourceforge.net/gnuwin32/wget-1.11.4-1-bin.zip
unzip wget-1.11.4-1-bin.zip
file bin/wget.exe
# bin/wget.exe: PE32 executable (console) Intel 80386 (stripped to
# external PDB), for MS Windows
I unpacked the .zip in my machine, uploaded the wget.exe to a
temporary place in my homepage, and my friend downloaded it with my
function `ee-very-primitive-wget0'. The download worked - the file
was not corrupted, it seems - but when he tried to execute that
wget.exe he got a message saying that that file was not compatible
with the version of Windows that we was using - which is "Microsoft
Windows 11 Home Single Language".
That's what we did today. More news soon...
Cheers,
Eduardo Ochs
http://angg.twu.net/#eev
next prev parent reply other threads:[~2021-10-06 4:50 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-03 4:26 Workshop to save M$ Windows users - help needed Eduardo Ochs
2021-10-03 5:45 ` Jean Louis
2021-10-03 7:59 ` Eduardo Ochs
2021-10-03 9:35 ` Eli Zaretskii
2021-10-03 10:19 ` Eduardo Ochs
2021-10-03 10:40 ` Eli Zaretskii
2021-10-03 19:15 ` Eduardo Ochs
2021-10-03 19:44 ` Tomas Hlavaty
2021-10-04 3:06 ` Eduardo Ochs
2021-10-04 17:34 ` Tomas Hlavaty
2021-10-04 18:29 ` Tomas Hlavaty
2021-10-06 4:50 ` Eduardo Ochs [this message]
2021-10-06 5:10 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-10-06 12:41 ` Eli Zaretskii
2021-10-07 16:32 ` Eduardo Ochs
2021-10-07 17:52 ` Tomas Hlavaty
2021-10-04 18:50 ` Eli Zaretskii
2021-10-06 4:19 ` Eduardo Ochs
2021-10-03 9:36 ` Tomas Hlavaty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CADs++6jX1awtv4WvPp4Rv+P5NTei0VH1ZFXRBq4eRYdxdPxQdw@mail.gmail.com \
--to=eduardoochs@gmail.com \
--cc=help-gnu-emacs@gnu.org \
--cc=tom@logand.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).