Page 10 of 20
Posted: Sun 06 Jan 2013, 22:58
by technosaurus
For security, if you add that to a daemonized script, you may want to set MYPASS="" immediately after you are finished with it.
Posted: Mon 07 Jan 2013, 01:37
by starhawk
BTW, I'm of the opinion that few puppy users (if any) really need an encrypted savefile.
Then again, I have nothing worth stealing, only partially on purpose.
Not to say, Jan99, that you shouldn't have one, just, I'm a little surprised when I come across someone who thinks it's necessary.
Only two people I can think of who really need it are Julian Assange (does he even use Puppy?) and that one dude that really doesn't like John Murga for some weird reason that I never fully understood.
Posted: Mon 07 Jan 2013, 05:25
by jpeps
starhawk wrote:...... and that one dude that really doesn't like John Murga for some weird reason that I never fully understood.
mental illness
Posted: Mon 07 Jan 2013, 05:33
by goingnuts
maddox: You need to escape the spaces:
Code: Select all
minimp3 01\ The\ Wall\ Street\ Shuffle\ -\ 10CC.mp3
or
mpg123 01\ The\ Wall\ Street\ Shuffle\ -\ 10CC.mp3
or
xhippo 01\ The\ Wall\ Street\ Shuffle\ -\ 10CC.mp3
when starting via command line. If you write the first part of the filename and "tab" shell does that for you (ex: "minimp3 01" & then "tab").
The cut&paste is know to kill some of the gtk1 aps -
view here. The error is a "Floating point exception" which terminates the application (I think its the source of the cut/copy that terminates).
Posted: Mon 07 Jan 2013, 19:14
by greengeek
goingnuts wrote:The cut&paste is know to kill some of the gtk1 aps -
view here. The error is a "Floating point exception" which terminates the application (I think its the source of the cut/copy that terminates).
You also mentioned the "minimal profit" text editor as an optional way around the problem:
http://murga-linux.com/puppy/viewtopic. ... 1&start=94
Seems to work well.
Posted: Mon 07 Jan 2013, 19:45
by goingnuts
Also adie from the FOX-lib - although quite big for a static build - seems to work.
For syntax highlight you need to place the Adie.stx file in same directory as you have installed adie and after that define the colors via Options/Preferences/styles
Posted: Tue 08 Jan 2013, 02:09
by postfs1
goingnuts wrote:
... mpg123 ...
Very interesting how long it will play sound.
jpeps wrote:starhawk wrote:...... and that one dude that really doesn't like John Murga for some weird reason that I never fully understood.
mental illness
Professional killer usually knows own victims, and two logins, which are in the quote, perhaps, have declared about own knowing.
pUPnGO
Posted: Tue 08 Jan 2013, 16:55
by Jan99
I am not an expert in this either (in fact more like a beginner )!
Managed to append some script lines to the mount script.
Now mount is reacting more as in other pups when it comes to encryption=
With a bonus that when I don't provide a mount-point it will do a fsck.
Unfortunatuly when unmounting the loop device is not freed and I do not know how to do it in a script (yet).
Manual free after unmount with losetup -d /dev/loop* works ok.
The lines I appended are:
if [ "$2" == "encryption=aes" ] || [ "$2" == "encryption=blowfish" ] || [ "$2" == "encryption=1" ] ; then
if [ "$2" == "encryption=aes" ] ; then
encryption=aes
else
if [ "$2" == "encryption=blowfish" ] ; then
encryption=blowfish
else
if [ "$2" == "encryption=1" ] ; then
encryption=1
fi
fi
fi
freeloop=$(/sbin/losetup -f)
losetup -e $encryption "${freeloop}" $3
if [ "$4" == "" ] ; then
fsck ${freeloop}
losetup -d ${freeloop}
exit
else
mount-FULL ${freeloop} $4
exit
fi
fi
Posted: Tue 08 Jan 2013, 19:15
by technosaurus
For future reference, here is a way to simplify that kind of code:
Code: Select all
case "$2" in
encryption=*)eval $2;;
esac
FYI
Recent versions of busybox mount automagically do losetup, not sure if that may cause an issue.
Posted: Tue 08 Jan 2013, 20:01
by goingnuts
Attached static builds of shutterbug (screen shot utility) and PathFinder (file manager) both from FOXlib 1.6.47. Although quite big they also seems quite feature rich and stable.
Posted: Wed 09 Jan 2013, 04:07
by Ibidem
goingnuts wrote:Attached static builds of shutterbug (screen shot utility) and PathFinder (file manager) both from FOXlib 1.6.47. Although quite big they also seems quite feature rich and stable.
Are you using libstdc++ or uclibc++? The latter should reduce binary size greatly, at least in theory...
pUPnGO 2012
Posted: Wed 09 Jan 2013, 19:39
by Jan99
pUPnGO busybox = V1.17.0
Original pup 412 busybox = V1.8.2 (clears loop device on unmount )
Have used busybox from pup412 in pUPnGO and then the loop device get cleared (just to test).
So i think it is a compile option of busybox (probably the encryption= too).
Thank you technosaurus that is simplifying a lot have changed code to:
case "$2" in
encryption=*)eval $2
freeloop=$(/sbin/losetup -f)
losetup -e $encryption "${freeloop}" $3
if [ "$4" == "" ] ; then
fsck ${freeloop}
losetup -d ${freeloop}
exit
else
mount-FULL ${freeloop} $4
exit
fi
::
esac
Posted: Fri 11 Jan 2013, 21:51
by goingnuts
Ibidem: libstdc++ - but I will try your suggestion using uclibc++ - thanks! Update: Actually seems that the binary gets slightly (14K) bigger with uclibc++ at least in my trials. Guess the big size of FOX-lib compiled static bins are mostly because FOX uses the X-lib extensively (?). Anyway - this can be reduced by combining the different applications in a multicall binary - which on the other hand needs a bunch of patching...
Jan99: I will look at the busybox compile...Update: I cant find any busybox configure flags that will turn on/of the clearing of loop device on unmount - so sort of stuck here...
Attached a draft for a gtkdialog1 GUI for creating and mounting aes-crypted files - sort of poor mans TrueCrypt...
Posted: Tue 15 Jan 2013, 16:13
by goingnuts
I have been revisiting the build of busybox as the question arise if the umount of loop devises could auto delete the used /dev/loop. This remains unsorted but another thing popped up that I will report for future reference. I have used the same busybox source for pupngo through all the versions and the last rebuild was in June 2012. Since then I have changed my uclibc toolchain but the new builds of busybox uses the same source and the same .config file...
But now I have a problem with the xterm-wrapper script which wont launch rxvt. The original part that fail is
This make rxvt error out with rxvt: unknown "" or something like that...
By replacing the line with
rxvt is happy again...but thats not how the shell should pass variables.
So upgraded/rebuild gcc/uclib/kernel headers but no change.
To make this a bit short the reason was sed (GNU version 4.1.2 - it is too old to build BB-20100217 correctly). Replacing sed with BB-sed from the version I was building solved this misbehavior...
Posted: Wed 16 Jan 2013, 18:31
by greengeek
Hi goingnuts - I am trying to work around a display problem I get when I use qtweb browser, and I think it has something to do with fonts and/or encoding so I was hoping you might have a suggestion:
The worst part of the symptom goes away when I remove the file /usr/share/fonts/default/TTF/h.pcf.gz but I don't know why. Do you have any idea what that file does? (seems odd to have a gz file in there, but it definitely has some effect on how the characters display...)
Symptoms as follows:
When I sign in to my webmail I see large crosses that obscure some areas. It seems to be some characters that may have different encoding (like ' apostrophes) and also characters that are "hidden" (like password entry fields). You can see this effect in pic 1.
Pic2 shows the effect after I remove the h.pcf.gz file. The crosses have been replaced by a less intrusive character. (but still doesn't show the ' character correctly). At least it's much more readable this way till I work out how to add the correct encoding or font.
Can you think of any downside of me leaving out that file permanently?
Posted: Wed 16 Jan 2013, 20:31
by goingnuts
greengeek:The h.pcf.gz origins from xwoaf and although a run of "mkfontdir" reveals only "h.pcf.gz -*-helvetica-*-r-*--13-130-*-*-*-*-*-*" the original xwoaf fonts.dir says:
h.pcf.gz -adobe-courier-medium-o-normal--12-*-*-*-*-*-*-*
h.pcf.gz -adobe-courier-medium-r-normal--12-120-75-75-m-70-iso8859-1
h.pcf.gz -*-times-medium-i-normal-*-14-*-*-*-*-*-*-*
h.pcf.gz -*-courier-medium-r-normal-*-14-*-*-*-*-*-*-*
h.pcf.gz -*-courier-bold-r-normal-*-14-*-*-*-*-*-*-*
h.pcf.gz -*-courier-medium-o-normal-*-14-*-*-*-*-*-*-*
h.pcf.gz -*-courier-medium-r-normal-*-12-*-*-*-*-*-*-*
h.pcf.gz -*-helvetica-bold-*-*--12-*-*-*-*-*-*-*
h.pcf.gz -*-helvetica-*-12*
I do not know how it was made so just used it. From time to time I try to get hold of the fonts in pupngo but I never really got a understanding of it...
Try to copy all original P412 fonts in there, remove the h.pcf.gz and see whats happening. You might also need to change the content of /etc/fonts...
The pupngo2012 has the gtkfonsel program but when choosing some of the present fonts it crashes.
Thats more or less what I can come up with...
Posted: Thu 17 Jan 2013, 04:55
by Ibidem
goingnuts wrote:I have been revisiting the build of busybox as the question arise if the umount of loop devises could auto delete the used /dev/loop. This remains unsorted but another thing popped up that I will report for future reference. I have used the same busybox source for pupngo through all the versions and the last rebuild was in June 2012. Since then I have changed my uclibc toolchain but the new builds of busybox uses the same source and the same .config file...
But now I have a problem with the xterm-wrapper script which wont launch rxvt. The original part that fail is
This make rxvt error out with rxvt: unknown "" or something like that...
By replacing the line with
rxvt is happy again...but thats not how the shell should pass variables.
So upgraded/rebuild gcc/uclib/kernel headers but no change.
To make this a bit short the reason was sed (GNU version 4.1.2 - it is too old to build BB-20100217 correctly). Replacing sed with BB-sed from the version I was building solved this misbehavior...
Hmm...don't get why that makes a difference.
Also, using "" for an argument is valid, so I don't see why "$EMPTYVAR" should be different, though I might be misunderstanding the issue.
"$MULTIWORD_VAR" is treated as a single argument, also.
FYI: Busybox 1.20.2 has a much more capable sed.
Posted: Fri 18 Jan 2013, 19:14
by goingnuts
Ibidem wrote:..
Hmm...don't get why that makes a difference.
Also, using "" for an argument is valid, so I don't see why "$EMPTYVAR" should be different, though I might be misunderstanding the issue.
"$MULTIWORD_VAR" is treated as a single argument, also.
FYI: Busybox 1.20.2 has a much more capable sed.
Hmm...tried to reproduce...seems not to be sed...seems to be the parsing of CFLAGS to already configured BB...strange...
I configure BB with
Code: Select all
CONFIG_EXTRA_CFLAGS="-static -Os -mtune=i386"
If I run just "make" the BB-binary seems ok...
If I run
Code: Select all
make CC="$CC_GLOBAL" CFLAGS="$CFLAGS_GLOBAL" LDFLAGS="$LDFLAGS_GLOBAL"
the binary is not ok and gives the errors described above with
even if CFLAGS=""...I do not get it!
If compiling busybox-1.20.2 the error does not occour...so considering upgrade to busybox-1.20.2 in future pupngo´s but who knows what will break then...initial test shows different behavior of wc...pmfree reports wrong free space etc.
Posted: Fri 18 Jan 2013, 21:44
by greengeek
Does puppy HAVE to have busybox? What would happen to Puppy if it used a full command set?
Posted: Sat 19 Jan 2013, 07:59
by Ibidem
greengeek wrote:Does puppy HAVE to have busybox? What would happen to Puppy if it used a full command set?
Can you spell B-L-O-A-T?
To elaborate, I can build a ~700k static busybox that provides everything needed to boot (I have run this as an OS). This equates to:
coreutils:12 MB
bash: 800k
dhcpcd (127 k) or dhclient 643 k
net-tools: 927k
module-init-tools: 340k
netcat: 192 k
sysklogd: 200 k
iputils-ping: 131 k
netbase: 98 k
sed: 52 k
awk: 322 k
util-linux: 2 MB
e2fs-progs: 2 MB
wget: 2 MB
bzip2: 156 k
...
ie, at least 20 MB.
Also you get slower startup, more RAM used, etc.