May I ask for some motivational use-case? =)
Has the 3.2 team been notified about the great RequestString suggestion and the Multiview search limitations?Yes, silence regarding RequestString, and a plain "no" on the Multiview search, it simply isn't available for Amiga guide datatype, and it isn't programmable.
One thing I also can recommend is to set the UHCREADER ENV variable to say Multiview or MuchMore.I looked into my ENVARC: the other day, so much UHC#? :)
Setenv UHC/VIEWER Multiview
It creates ENV:UHC folder and the ENV:UHC/VIEWER file with correct content.SetEnv SAVE UHC/VIEWER Multivew
does not create ENVARC:UHC folder and ENVARC:UHC/VIEWER file...The use case is when the Amiga system's isn't really online, but only is on a IPv4 peer-to-peer link to a modern system, that is on an IPv6-only LAN, using NAT64/DNS64 to access the legacy IPv4-only services - such as the UHC search sites - perhaps not a common scenario today, but one that may become more and more common in time ;)
I looked into my ENVARC: the other day, so much UHC#? :)
Perhaps an idea to put them in a folder? ${UHC/VIEWER} for example..
Damn, I now found another bug in OS 3.1.4 (and earlier)...Code: [Select]Setenv UHC/VIEWER MultiviewIt creates ENV:UHC folder and the ENV:UHC/VIEWER file with correct content.
HoweverCode: [Select]SetEnv SAVE UHC/VIEWER Multivewdoes not create ENVARC:UHC folder and ENVARC:UHC/VIEWER file...
The use case is when the Amiga system's isn't really online, but only is on a IPv4 peer-to-peer link to a modern system, that is on an IPv6-only LAN, using NAT64/DNS64 to access the legacy IPv4-only services - such as the UHC search sites - perhaps not a common scenario today, but one that may become more and more common in time ;)
Sounds like a very dark future, I do hope we as a community have an IPV6 capable TCP/IP stack at that time.
@kolla:
So if you want to use UHCSearch as it is now, how do you do it?
I looked into my ENVARC: the other day, so much UHC#? :)
Perhaps an idea to put them in a folder? ${UHC/VIEWER} for example..
8.Ram Disk:> uhcstatus
UHC Revision: 4938182ec00a058d1b126b02a8b3a53218cdf600
Type: ENV: Value:
Location UHCBIN SYS:UHC/
Temp Location UHC/TEMPDIR T:
Reader UHC/READER RES MuchMore
Show Archiver UHC/SHOWARCHIVER No
Show DL Progress UHC/SHOWPROGRESS Yes
Aminet Mirror UHC/AMINETMIRROR de.aminet.net/aminet/A bit tidier?Yes, very cool, thanks :)
@kolla:
So if you want to use UHCSearch as it is now, how do you do it?
At home, I general, I don't.
I have my own aminet mirror and an "aminet search" is rsh+ssh to the BSD box that holds the mirror, via a raspberry pi, where it just performs a grep on the INDEX file :)
But I have my Minimig and MiSTer at work, where I've used UHCSearch as intended.
A work-around for my home-situation is to make an ipv4-tunnel from the home Amiga systems to some cloud service, for example (though these days some providers offer cheaper VPS instances when you make them IPv6-only...)
We have changed UHCSearch to use HTTP, so now it should be as firewall friendly as possible.
It also supports sending the requests via a HTTP proxy by using the http_proxy ENV-variable.
Please report any issues you find.
Code: [Select]8.Ram Disk:> uhcstatus
UHC Revision: 4938182ec00a058d1b126b02a8b3a53218cdf600
Type: ENV: Value:
Location UHCBIN SYS:UHC/
Temp Location UHC/TEMPDIR T:
Reader UHC/READER RES MuchMore
Show Archiver UHC/SHOWARCHIVER No
Show DL Progress UHC/SHOWPROGRESS Yes
Aminet Mirror UHC/AMINETMIRROR de.aminet.net/aminet/
IF "$UHC/AMINETMIRROR" EQ "*$UHC/AMINETMIRROR", which of course should be IF "${UHC/AMINETMIRROR}" EQ "*${UHC/AMINETMIRROR}" like it is in aminetreadme
I noticed that aminetget and aminetextract now always resets ${UHC/AMINETMIRROR} to "de.aminet.net/aminet/" - the culprit beingCode: [Select]IF "$UHC/AMINETMIRROR" EQ "*$UHC/AMINETMIRROR", which of course should beCode: [Select]IF "${UHC/AMINETMIRROR}" EQ "*${UHC/AMINETMIRROR}"like it is in aminetreadme
When debugging the above issue, I noticed that the SetFromCmd fails (or rather, creates unwanted output so that uhcget fails), when the shell is running with "set ech on" - perhaps a long talk with Thomas Richter about stdout vs stderr can enlighten you on how this can be fixed :)
HTTP proxy by using the http_proxy ENV-variable.
List UHC:UHC-User-Startup/ LFORMAT="Execute ${UHCBIN}UHC-User-Startup/%N" >T:UHC-User-Startup.temp
List UHC:UHC-User-Startup FILES PAT "~(#?.info)" LFORMAT="Execute *"%P%N*"" >T:UHC-User-Startup.temp
A bug report…
This stopped working with "AsyncHTTPGet 0.84 ( 7.jan.23)", I now get "10.99.0.1:8888: Host name lookup failure (2)" when trying to download anything. Previous aget works fine.
Also a suggestion, in UHC-Startup…
Replace…
List UHC:UHC-User-Startup/ LFORMAT="Execute ${UHCBIN}UHC-User-Startup/%N" >T:UHC-User-Startup.temp
with (for example)…
List UHC:UHC-User-Startup FILES PAT "~(#?.info)" LFORMAT="Execute *"%P%N*"" >T:UHC-User-Startup.temp
Some editors leave .info files, and Execute doesn’t handle it well when told to execute them.
(and I don’t quite grasp why there would be any reason for not using %P?)
Hello Patrik!
For a few weeks now, updates in Aminet has not been showing, that is, aminetrecent seem "stuck" with fe.lha as latest upload, and that was 2023-03-02. I've just been taking it for granted that someone else would report this, cannot believe I'm the only one who regularly check for aminet updates using UHC :)
Using latest uhc-tools (according to uhcupdate)
I see that aminetrecent uses ${UHC/SEARCHURL}, which is uhc.driar.se/uhcsearch - if I remove the var, an "aminetrecent" reinstates it.