Puppy Linux Discussion Forum

Wow.
The bookworm64 is the best ive seen since puppy precise. It is so good Im considering testing linux after 10 years abscence. Problem to solve is debloating (another thread here) and how to find device path to usb, i know this is almost impossible in linux but perhaps things evolved ?

Setup ; 64 bit computer, frugal install bookworm64 on usb. Analog measuring board connected on usb, usb connection registrers according to dmesg at connection but no device path (?). This analog board has extremely uniqe software running in wine and to my surprise worked after only 2 hours linux tinkering. So only obstacle now is to find out if linux is able telling me exact device path to the usb port so i can make correct paths in wine. Commands such as lsusb is useless as they lists bus number and not the exact device path linux is using internally for the usb device.

Kudos to peebee et al for an excellent distro.

Try lsblk ?

Thank you for reply. Yes lsblk is one of all commands i tested but if i remember correct also lsblk only showed bus and node number of the usb device, not how to address it from within linux (?).

Tested after this post is also usbview application that also tells me the bus and node number which luckily matched all the other commands i tried. It was decided i will pause linux for a while as this was not possible to fix so I will not check in here so often now.

It should show up as '/dev/ttyUSB0' or something similar. You can set it up using the 'stty' command if needed:

stty -F /dev/ttyUSB0 9600 cs8 -cstopb -parenb

jhg wrote: Tue Oct 10, 2023 6:06 pm

Thank you for reply. Yes lsblk is one of all commands i tested but if i remember correct also lsblk only showed bus and node number of the usb device, not how to address it from within linux (?).

Oh well, maybe I don't understand your original question, but seems to me that lsblk command does indeed indicate where your usb devices are (the /dev name location which is what is then used to mount the device by linux commands). For example, if I plug in my first usb stick, and run lsblk, it sees it and correctly tells me sdb1 and so on for the various partitions I have on it. So thereafter I can use mount /dev/sdb1 /somedir to do the actual mounting. If a Puppy utility does that automatically I think it uses the mountpoint /mnt/sdb1, for example. The sdb1 reported by lsblk is the dev device used, but if you are no longer checking in here I guess you are not reading more anyway.

It was decided i will pause linux for a while as this was not possible to fix so I will not check in here so often now.

You post a issue on a forum that has people all over the world on it.
Half of us are sleeping at any one time.

Give us two days to even see your topic, try to understand what you are asking, and think about what you can do.

Make two posts and leave.

Every day this is proven.

What you do not tell us is the clue to finding the solution.

I am not completely sure what you are trying to do, Are you???

i know this is almost impossible in linux but perhaps things evolved ?

Everything is possible in Linux!
We prove it every day on this forum!!

Edit2: During a break I realized that your post reveals both Bookworm and the Analog measuring board program are on the USB-Key. So, some of the following may be inaccurate/unnecessary. During the creation of Wine-portable mentioned below Mikewalsh and I had to figure out how to establish Menu listings for wine's builtin-programs --which would be located within the wine-prefix-- and external portable programs, which would not. But I want to boot into Bookworm and setup the Wine-portable to refresh my memory and check the script's used.

Come back later when the following may have been substantially changed. Edit: See my next post.
-=-=--=-=-

I may be completely off, but I think jhg's problem is that the setup involves a USB-Key. It's relatively easy to write Linux code to start a program under wine when the executable has a known location. But the location of USB-Keys and partitions on them are dynamically established anew each time Linux boots.

Question: Is the Analog measuring board program 'installed' into the Wine prefix? Or is it a 'portable' that can be run from anywhere once Wine is started?

Question: Is the Analog measuring board program on the USB-Key or on a different partition with only 'a template' it will use on the USB-Key? Edit: Reading the OP answered this question.

Possible solution either way: Uninstall the current version of Wine. Use Mikewalsh's Wine-portable 5.11* from here, https://www.forum.puppylinux.com/viewto ... 191#p68191. Wine-portable locates the wine-prefix within its own folder. So installed programs have a known location relative to the wine-executable. And portable windows programs can be located within the portable's folder so, once again, they have a known location relative to the Wine-executable.

Wine-portable can be located within /opt; from the same partition as the Bookworm occupies but external to Bookworm files, or from a USB-Key. With the first two, menu entries can be created. But because the path to USB-Keys are dynamically set one would have to run Wine-portable's included WINE-Link script on each boot-up. Another script could then run the Analog measuring board program whether within the wine-prefix or external.

The only alternatives I can think of is to start the program via a script which searches all partitions for a specific file and sets the path relative to it. Or maybe somehow employing

HERE="$(dirname "$(readlink -f "$0")")"

in a script. But as you all know, scripting isn't my forte.

-=-=--=-
The portable makes use of a version 5.11 Wine AppImage. See https://www.forum.puppylinux.com/viewto ... 075#p68075 for instructions to use a different AppImage.

As indicated in my previous post, I used Wine-portable version 5.11. The portable folder resides on the same partition as Bookworm's folder, but is external to it. That that partition was on a hard-drive rather than a USB-Key doesn't matter as Bookworm, itself, doesn't care if boots from a hard-drive or a USB-Key. What does matter is that both were on the same partition. [It probably would be sufficient if they were on the same drive but different partitions. But that wasn't tested and would add complications to determining 'the path']*.

The WINE-Link script within the Wine-portable was executed creating links between it and Bookworm. This has to be done once unless you choose not to execute a SAVE. Caution: Creating the links did not automatically establish associations between Bookworm and 'exe' files. What I had to do was Right-Click an exe, select 'Set Run Action' and --the programs I tested being 32-bit-- type wine32 in front of "$@". If the program was a 64bit, the command would have been wine64.

There may be an application to determine the path to a file. I don't know it. I think using Thunar, you can 'cut-&-paste'. Bookworm uses rox. So I took screen shots of the location of the executables of two programs. One was SumatraPDF which had been installed into Wine-portable's prefix. The other was EssentialPIM, a portable program whose folder was merely located within the Wine-Portable Folder.

Using the information provided in Rox's Titles to both programs, I wrote these executable bash-scripts:

#!/bin/sh
wine32 /initrd/mnt/dev_save/WINE_5.11-portable64/EssentialPim-042823/EssentialPIM.exe

and

#!/bin/sh
wine32 /mnt/home/WINE_5.11-portable64/WINE/wine/drive_c/'Program Files'/SumatraPDF/SumatraPDF.exe

Both opened their respective programs.

Note under Puppy /mnt/home is actually a symlink to /initrd/mnt/dev_save. It may be possible to get by without enclosing 'Program Files' in quotes**. You can reduce the amount you have to write by simplifying the name of the Wine portable folder. Likely just WINE will suffice. The same may be true of the names of the folders holding the programs. EssentialPim-042823 could probably be reduced to EssentialPIM, or maybe even Jane. Once you have the path to where the portable locates installed programs [WINE_5.11-portable64/WINE/wine/drive_c/'Program Files'] it can be copied as only the specific programs folder and executable [e.g. SumatraPDF/SumatraPDF.exe] will differ.

The same is true of portables as long as you locate them within the Wine Portable folder: e.g. /initrd/mnt/dev_save/WINE_5.11-portable64/NAME-OF-PORTABLE'S-FOLDER/PORTABLE'S EXECUTABLE.

There are posts of the Forum spelling out how to create Menu entries using a bash-script, a pixmaps and a file in /usr/share/applications named SOMETHING desktop. IIRC, you don't even need the bash-script: you can spell-out the command as the desktop file's Exec= argument.

I don't know why something similar to the above can't be done even if you installed Wine rather than use a portable. That's what I used to do before Mikewalsh devised the Wine-portable format.

I've only run across one complicating factor. I have a program that uses templates. The templates can be anywhere. But if I change the location of the program I have to again select the template by using the template selection procedure OF the program. Using the Wine portable this also only has to be done once: the portable locates its configuration files within its own folder.

=---=-=--=--
* Bookworm's (any Puppy's) home partition is always the partition holding its system files unless the User chooses to create a SaveFile/Folder and locates that on a different partition. In that case, that different partition will be the home partition. A Puppy always knows the path to it's home partition, even if we chose to refer to that partition as /initrd/mnt/dev_save or by the symlink to it called /mnt/home. The problem that dynamic assignment of partitions within a system of identifying the path to other partitions on a USB-Key or even a hard-drive doesn't arise when all relevant files and folders are on the home partition.

** Not recommended. Linux usually reads a space between names as a FULL STOP and does generating a 'File Not Found' error. Sometimes --for reasons I don't understand--you can get away without placing a divided name within quotes. Don't count on not having a problem the next time.