<SiFuh>
Question, these hashes are in pairs. I was learning about hashes today. Is it possible to do them in in tripplets?
<farkuhar>
I've seen hashes initialized like so: ( opt1 => [1,2], opt2 => [3,4], opt3 => [5,6] ); When you look up the value associated with key opt3, you can interpret [5,6] as array subscripts. Is that what you had in mind, SiFuh?
<SiFuh>
Cool it is an idea. I plan to make a perl script that will mount OpenBSD encrypted drives when I plug them in and run the script. It will need the DDUID of the disk that is encrypted and then when it has been unlocked with the password it will need the DDUID of the unlocked disk but associated with the disk label.
<SiFuh>
So for example sd0 is the encrypted disk. It will have a DDUID that I will use to find out if it really is sd0. Once the password has been entered a new disk appears maybe sd1 and it will have its own DDUID.
<SiFuh>
The mount point will be based on the label so maybe the disk is labeled RABIES and that would mean the mountpoint will be /mnt/RABIES
<farkuhar>
Luckily I haven't run into any segfaults while testing prt-auf. Maybe the compiler has gotten a lot smarter in the decades since groovy2shoes was actively coding in Perl. But the task that caused groovy2shoes' code to segfault (dereferencing a scalar and using the value as a key for some other data structure) is essentially how the higher-dimensional lookup tables are implemented, for applications like what SiFuh has in mind.
<SiFuh>
I am still a beginner, my script is way off. I prefer to become more knowledgable in perl first. I only started studying it a few days back
<farkuhar>
It was really helpful while coding prt-auf to have a fixed standard against which to compare its behaviour. If you're building something from scratch and don't have a reference of how the program ideally behaves, you end up having too much freedom to experiment with alternative solutions.
<SiFuh>
My shell scripts work fine. But for my first real project I have chosen this. I will be writing it from scratch for sure. Hopefully with the perl lessons fresh on my mind it will be okay.
<SiFuh>
I also plan to merge all the different drives into the one program. Hence the consept of using the hashes
<SiFuh>
I have been reading this one https://www.perltutorial.org/ I am up to perl if statements. Been messing around with each project and modifying them for fun. Found a few errors on that site though. He uses the wrong double quotes sometimes.
<farkuhar>
I agree, hashes are the way to do it. One of the biggest annoyances when diving into an unfamiliar code base is to see entire blocks just copied and pasted, rather than generalized to handle a wider variety of inputs. "Don't repeat yourself" is the motto I tried to follow.
<SiFuh>
Yeah, I don't copy and paste. I simplify everything as much as possible. If I need to use something twice, I turn it into a function I call and so on
<SiFuh>
I turn it into a function I cna call upon and so*
<SiFuh>
...
<SiFuh>
farkuhar: Those extra functions like dup and listorphans under GENERAL INFORMATION are not originally part of prt-get but were seperate scripts right?
<farkuhar>
SiFuh: I haven't been using CRUX as long as you have, but I believe those functions were already part of prt-get when I started at CRUX 3.2
<SiFuh>
I always thought they were extra scripts
<SiFuh>
Nice if it is all included into one script
<farkuhar>
On reading the ChangeLog, it appears that listorphans was introduced in 2006 (version 0.5.12). I can't see any mention of when the dup command was introduced.
<SiFuh>
A non-local port search function would be nice
SiFuh has quit [Remote host closed the connection]
SiFuh has joined #crux
<SiFuh>
prt-search.sh firefox
<SiFuh>
farkuhar: jmq is your repo?
<farkuhar>
SiFuh: yes, that's my repo.
<SiFuh>
Cool
<SiFuh>
I guessed because of the jmq.git Haha
<SiFuh>
ncdu fix build for newest ffmpeg <-- :-P
<SiFuh>
Will bookmark your scripts folder, I may pick up some cool ideas as reference in the future
<farkuhar>
Yeah, back then I hadn't yet established the habit of making very granular git commits. I would make a bunch of changes and then commit them all with a message that only applied to a subset of the edits.
<SiFuh>
Yeah, I do mine one by one. cd telegram-bin. Do some hocus pocus. pkgmk -is. If builds fine and the footprint is fine, I run a script 'yenjie'.
<farkuhar>
I should really rename that port as ncdu-bin, anyway, because it's not compiled by build(), only unpacked. Without making a port for the Zig compiler, there's no way to use that fork of ncdu except as a binary.
<SiFuh>
I am not sure if that is a thing. I just do *-bin for anything that is binary and shove it under /opt
<SiFuh>
beerman has a much more complicated script with fancy facial expressions in ascii
<SiFuh>
I find it unsual that qBittorrent wants to open the folder location with the $BROWSER variable and it seems it will send file:///folder/location/foo bar/ to the program or maybe xdg-open.
<SiFuh>
But mc does not seem to be able to open 'file://' so I was able to strip that and I have tried to replace the spaces with '\ ' but it still won't open the folders with spaces in their names. So I am wondering if it is getting cutt off at the space.
<SiFuh>
So instead of 'file:///folder/location/foo bar/' I am getting 'file:///folder/location/foo'. Maybe?
_moth_ has quit [Remote host closed the connection]
_moth_ has joined #crux
<farkuhar>
Whitespace in command-line arguments is notorious for causing problems. It's especially problematic if you need to pass a whitespace-separated option to a child process from a wrapper program, as in prt-get --aargs="--install-root /mnt/MUCORMYCOSIS" depinst qbittorrent
<SiFuh>
This strips the file:// from the start of whatever qbittorrent is sending.
<SiFuh>
I will work on the white spaces, brackets and other characters later but at the moment the white spaces part isn't working even when I replace them with a '\' in front
<SiFuh>
Jan. 6 committee reveals nothing but staged bullshit and lies.
<farkuhar>
Shell quoting is another one of those places where it's too easy to get it wrong. The --regex switch in prt-auf is currently giving weird results, either because the metacharacters aren't adequately protected from the shell, or because the variable they're assigned to isn't enclosed in the right quotes in the Perl program.
<SiFuh>
I see
<groovy2shoes>
SiFuh, i'd do "${@#file://}" partly because it's more readable and partly because it'll only strip 'file://' off the front. i don't think it'll fix your problem, tho. i'm getting the same output either way with my test.