sfs_load-2.4 on-the-fly

Miscellaneous tools
Post Reply
Message
Author
jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

Re: finding whiteout

#101 Post by jpeps »

Shep wrote:
Most probably you have a file that does match .wh* in your current directory and find can discover no identically-named file existing in /initrd/pup_rw.
What's interesting, though, is that it finds files (without quotes) in sh shell but not bash.
jim1911 wrote:
Gcompris did not run when SFS-Load offered to run it, however it runs fine from the console.
I'd say that feature needs bit of refinement (or just drop it).

User avatar
shinobar
Posts: 2672
Joined: Thu 28 May 2009, 09:26
Location: Japan
Contact:

SFS launcher

#102 Post by shinobar »

Jim1911 wrote:Gcompris did not run when SFS-Load offered to run it, however it runs fine from the console. :D
I know the issue(PATH problem), but have not found the solution yet... :(
Downloads for Puppy Linux [url]http://shino.pos.to/linux/downloads.html[/url]

Shep
Posts: 878
Joined: Sat 08 Nov 2008, 07:55
Location: Australia

Re: finding whiteout

#103 Post by Shep »

jpeps wrote:
Shep wrote:
Most probably you have a file that does match .wh* in your current directory and find can discover no identically-named file existing in /initrd/pup_rw.
What's interesting, though, is that it finds files (without quotes) in sh shell but not bash.
Sounds like you must be using different binaries for sh and bash? Usually /bin/sh is just a link to /bin/bash.

With Wary 5.1 I can get no difference in behaviour of /bin/sh vs. /bin/bash.

This sample illustrates the hazard of omitting needed quotes:

Code: Select all

# cd /tmp
# /bin/bash
# ls .wh*
ls: cannot access .wh*: No such file or directory
# echo x >.whAA
#  find /initrd/pup_rw  -mindepth 2 -type f -name .wh*
#  find /initrd/pup_rw  -mindepth 2 -type f -name ".wh*"
/initrd/pup_rw/lib/modules/all-firmware/.wh.cdcacm.tar.gz
/initrd/pup_rw/lib/modules/all-firmware/.wh.hso.tar.gz
/initrd/pup_rw/lib/modules/all-firmware/.wh.ipwireless.tar.gz
/initrd/pup_rw/lib/modules/all-firmware/.wh.nozomi.tar.gz
/initrd/pup_rw/lib/modules/all-firmware/.wh.usbserial.tar.gz
/initrd/pup_rw/dev/.wh.sr1
#
# echo x >.whBBBB
#  find /initrd/pup_rw  -mindepth 2 -type f -name .wh*
find: paths must precede expression: .whBBBB
Usage: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec] [path...] [expression]
#  find /initrd/pup_rw  -mindepth 2 -type f -name ".wh*"
/initrd/pup_rw/lib/modules/all-firmware/.wh.cdcacm.tar.gz
/initrd/pup_rw/lib/modules/all-firmware/.wh.hso.tar.gz
/initrd/pup_rw/lib/modules/all-firmware/.wh.ipwireless.tar.gz
/initrd/pup_rw/lib/modules/all-firmware/.wh.nozomi.tar.gz
/initrd/pup_rw/lib/modules/all-firmware/.wh.usbserial.tar.gz
/initrd/pup_rw/dev/.wh.sr1
#
Results are identical with what I get for /bin/sh

So your finding is interesting, insofar that it seems to indicate different binaries for sh and bash.

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

Re: finding whiteout

#104 Post by jpeps »

Shep wrote: Results are identical with what I get for /bin/sh

So your finding is interesting, insofar that it seems to indicate different binaries for sh and bash.
Since you're interested :D

Here I start in normal root sh shell (Lucid). Switching to bash takes me to user "spot", since /etc/passwd lists bash shell ( I need to use "sudo" to have root privileges or find doesn't work well).

Code: Select all

~ # whoami
root
~ # find /initrd/pup_rw  -mindepth 2 -type f -name .wh*
/initrd/pup_rw/var/local/icons/.wh..wh..opq
/initrd/pup_rw/dev/usb/.wh.lp0
/initrd/pup_rw/etc/.wh.windowmanager.openbox
/initrd/pup_rw/etc/ssl/misc/.wh..wh..opq
/initrd/pup_rw/usr/lib/openoffice.org3/share/uno_packages/cache/uno_packages/.wh.SH1dMc_
/initrd/pup_rw/usr/lib/openoffice.org3/share/uno_packages/cache/uno_packages/.wh.SH1dMc
/initrd/pup_rw/usr/lib/engines/.wh..wh..opq
~ # bash
~ $ whoami
spot
~ $ sudo find /initrd/pup_rw  -mindepth 2 -type f -name .wh*
~ $ sudo find /initrd/pup_rw  -mindepth 2 -type f -name ".wh*"
/initrd/pup_rw/var/local/icons/.wh..wh..opq
/initrd/pup_rw/dev/usb/.wh.lp0
/initrd/pup_rw/etc/.wh.windowmanager.openbox
/initrd/pup_rw/etc/ssl/misc/.wh..wh..opq
/initrd/pup_rw/usr/lib/openoffice.org3/share/uno_packages/cache/uno_packages/.wh.SH1dMc_
/initrd/pup_rw/usr/lib/openoffice.org3/share/uno_packages/cache/uno_packages/.wh.SH1dMc
/initrd/pup_rw/usr/lib/engines/.wh..wh..opq
~ $ 
edit: Actually, I think this has more to do with running a user shell on top of the root shell. If I switch to sh shell with user "spot", it's the same as it was with bash.

confirmed:

Code: Select all

~ # echo $0
bash
~ # find /initrd/pup_rw  -mindepth 2 -type f -name .wh* 
/initrd/pup_rw/var/local/icons/.wh..wh..opq
/initrd/pup_rw/dev/usb/.wh.lp0
/initrd/pup_rw/etc/.wh.windowmanager.openbox
/initrd/pup_rw/etc/ssl/misc/.wh..wh..opq
/initrd/pup_rw/usr/lib/openoffice.org3/share/uno_packages/cache/uno_packages/.wh.SH1dMc_
/initrd/pup_rw/usr/lib/openoffice.org3/share/uno_packages/cache/uno_packages/.wh.SH1dMc
/initrd/pup_rw/usr/lib/engines/.wh..wh..opq

Shep
Posts: 878
Joined: Sat 08 Nov 2008, 07:55
Location: Australia

#105 Post by Shep »

So you've concluded that the shells do not function differently, but it's the different user that causes find to produce the different output.

I could account for this if in the current directory there was a file whose permissions did not allow spot to list it. User root would see it, but user spot would not. For my hunch to be borne out as correct, though, your finding would need to be the exact opposite to what you show. :cry:

Run as root, find ......... .wh* would see some local file matching .wh* and likely be unsuccessful in finding an identically-named one in /initrd/pup_rw
If I switch to sh shell with user "spot", it's the same as it was with bash.
But the block of code you provide in confirmation isn't the block that would confirm it. :roll:
I think you have in haste simply duplicated the last part of the first example?

Any idea why the behaviour is as you found it? The mystery has merely shifted focus. :)

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#106 Post by jpeps »

Shep wrote: I think you have in haste simply duplicated the last part of the first example?
not haste :) I ran the root shell as "bash" instead of "sh" to confirm that both act similarly.
Any idea why the behaviour is as you found it? The mystery has merely shifted focus. :)
Yes; it needs .wh\* to find it when not in root shell. For some reason, in root shell '*' doesn't need to be escaped.

Code: Select all

sudo find /initrd/pup_rw  -mindepth 2 -type f -name .wh\* 
/initrd/pup_rw/var/local/icons/.wh..wh..opq
/initrd/pup_rw/dev/usb/.wh.lp0
/initrd/pup_rw/etc/.wh.windowmanager.openbox
/initrd/pup_rw/etc/ssl/misc/.wh..wh..opq
/initrd/pup_rw/usr/lib/openoffice.org3/share/uno_packages/cache/uno_packages/.wh.SH1dMc_
/initrd/pup_rw/usr/lib/openoffice.org3/share/uno_packages/cache/uno_packages/.wh.SH1dMc
/initrd/pup_rw/usr/lib/engines/.wh..wh..opq
Shep wrote: The dot is not a wildcard to the shell, so escaping it with a backslash achieves nothing.
:lol:
Last edited by jpeps on Mon 28 Feb 2011, 08:13, edited 1 time in total.

User avatar
Q5sys
Posts: 1105
Joined: Thu 11 Dec 2008, 19:49
Contact:

Re: finding whiteout

#107 Post by Q5sys »

jpeps wrote:[edit: Actually, I think this has more to do with running a user shell on top of the root shell. If I switch to sh shell with user "spot", it's the same as it was with bash.
And what exactly is the purpose of opening a shell to open a shell as you were doing? Am I missing something?

As far as the puppies ive used in the past including LHP currently... sh is a symlink to bash.

Shep
Posts: 878
Joined: Sat 08 Nov 2008, 07:55
Location: Australia

#108 Post by Shep »

jpeps wrote: Yes; it needs .wh\* to find it when not in root shell. For some reason, in root shell '*' doesn't need to be escaped.
Hmm. Surely there isn't an environment setting such as expandwildcards=false :?:
Though different for root and spot?

So we are no nearer understanding the apparent anomaly?

What about:

Code: Select all

 USER=root find /initrd/pup_rw  -mindepth 2 -type f -name .wh* 
 USER=spot find /initrd/pup_rw  -mindepth 2 -type f -name .wh* 
Shep wrote: The dot is not a wildcard to the shell, so escaping it with a backslash achieves nothing.

A dot is not an asterisk. 8)

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#109 Post by jpeps »

Shep wrote:
What about:

Code: Select all

 USER=root find /initrd/pup_rw  -mindepth 2 -type f -name .wh* 
The dot is not a wildcard to the shell, so escaping it with a backslash achieves nothing.
 USER=spot find /initrd/pup_rw  -mindepth 2 -type f -name .wh* 
no cigar

"The dot is not a wildcard to the shell, so escaping it with a backslash achieves nothing."

A dot is not an asterisk. 8)
right...should have escaped the wildcard (although you can't use both quotes and '\*'). That said, dots are special characters in search patterns, so it's not a bad idea to get used to escaping them as well. Always better to write safe code to begin with that will cover all situations.

Shep
Posts: 878
Joined: Sat 08 Nov 2008, 07:55
Location: Australia

#110 Post by Shep »

jpeps wrote:no cigar

Realised as soon as I'd posted that it wouldn't. The su command exists for a reason.
I'm trying to replicate the essence of your finding on Wary. Should be possible, you reckon?

So I get to a shell (shouldn't matter whether sh or bash, you say) and ....

Code: Select all

sh-3.00# echo $USER
root
sh-3.00# find /initrd/pup_rw  -mindepth 2 -type f -name .wh* 
/initrd/pup_rw/lib/modules/all-firmware/.wh.cdcacm.tar.gz
/initrd/pup_rw/lib/modules/all-firmware/.wh.hso.tar.gz
/initrd/pup_rw/lib/modules/all-firmware/.wh.ipwireless.tar.gz
/initrd/pup_rw/lib/modules/all-firmware/.wh.nozomi.tar.gz
/initrd/pup_rw/lib/modules/all-firmware/.wh.usbserial.tar.gz
/initrd/pup_rw/dev/.wh.sr1
sh-3.00# su spot
sh-3.00$ echo $USER
spot
sh-3.00$ find /initrd/pup_rw  -mindepth 2 -type f -name .wh* 2>/dev/null
/initrd/pup_rw/lib/modules/all-firmware/.wh.cdcacm.tar.gz
/initrd/pup_rw/lib/modules/all-firmware/.wh.hso.tar.gz
/initrd/pup_rw/lib/modules/all-firmware/.wh.ipwireless.tar.gz
/initrd/pup_rw/lib/modules/all-firmware/.wh.nozomi.tar.gz
/initrd/pup_rw/lib/modules/all-firmware/.wh.usbserial.tar.gz
/initrd/pup_rw/dev/.wh.sr1
sh-3.00$ 
The fact that I needed to discard lots of diagnostic messages while your spot didn't elicit any permission-denied messages gives pause for thought. :? Why was your spot able to descend into directories that presumably have root-only permissions? That's probably a more important question. :!: :!:

Any thoughts on that?

Shep
Posts: 878
Joined: Sat 08 Nov 2008, 07:55
Location: Australia

Re: finding whiteout

#111 Post by Shep »

Q5sys wrote:And what exactly is the purpose of opening a shell to open a shell as you were doing?
How would you have done it?

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#112 Post by jpeps »

Shep wrote: The fact that I needed to discard lots of diagnostic messages while your spot didn't elicit any permission-denied messages gives pause for thought. :? Why was your spot able to descend into directories that presumably have root-only permissions? That's probably a more important question. :!: :!:

Any thoughts on that?
requires sudoers for root privileges:

http://murga-linux.com/puppy/viewtopic.php?t=60258

User avatar
Q5sys
Posts: 1105
Joined: Thu 11 Dec 2008, 19:49
Contact:

Re: finding whiteout

#113 Post by Q5sys »

Shep wrote:
Q5sys wrote:And what exactly is the purpose of opening a shell to open a shell as you were doing?
How would you have done it?
Um... I'm not understanding the reason of opening a shell to open a shell. Hence my question of what im missing. What is the reason you cant open one shell and issue the commands there? Whats the purpose of opening a nested shell inside the first one? Thats what Im not getting.

Nested shells make me think of the yo dawg meme...
Image

Shep
Posts: 878
Joined: Sat 08 Nov 2008, 07:55
Location: Australia

Re: finding whiteout

#114 Post by Shep »

Q5sys wrote:Um... I'm not understanding the reason of opening a shell to open a shell.
It's more a case of first opening a console, then running the desired shell. The fact that the console defaults to opening with bash means that you need to get sh running if you want to test sh.

It could be done differently, but who cares? Shells are just programs, so for the case in question, it shouldn't be a problem. Finish with exit to return to bash.

Could use exec sh if you don't need to return to bash.

:)

User avatar
Q5sys
Posts: 1105
Joined: Thu 11 Dec 2008, 19:49
Contact:

Re: finding whiteout

#115 Post by Q5sys »

Shep wrote:
Q5sys wrote:Um... I'm not understanding the reason of opening a shell to open a shell.
It's more a case of first opening a console, then running the desired shell. The fact that the console defaults to opening with bash means that you need to get sh running if you want to test sh.

It could be done differently, but who cares? Shells are just programs, so for the case in question, it shouldn't be a problem. Finish with exit to return to bash.

Could use exec sh if you don't need to return to bash.

:)
Ok I ask, because Im hoping to further educate myself about this. So dont think i'm being a smart ass. lol.
What benefits are there to opening a shell within a shell versus using the exec command? In the past when I needed to open a shell and run something (like htop for a simple example) I've used exec. Is there any benefit to nesting shells?

ps... sorry to hijack your thread. :)

User avatar
jim3630
Posts: 791
Joined: Mon 14 Feb 2011, 02:21
Location: Northern Nevada

#116 Post by jim3630 »

shinobar, thanks for the pet it worked in my fatdog 64 511 without a hitch today. what a work saver! thanks again jim

Shep
Posts: 878
Joined: Sat 08 Nov 2008, 07:55
Location: Australia

Re: finding whiteout

#117 Post by Shep »

Q5sys wrote:What benefits are there to opening a shell within a shell versus using the exec command?
Well, there's less typing for a start. :wink:

No great drawback as far as I can see, provided you are not running low on memory.

It means that you can test a bit of code (e.g., by running it in various shells, ksh, zsh, dash, ash, bash, ...) then return to what you were doing. It's a straightforward way to inherit data, if that's desired. Inheritence goes only one way:

Code: Select all

# echo $0
bash
# echo $word

# export word
# word='Some important string or data'
# echo $word
Some important string or data
# sh
# echo $word
Some important string or data
# word='changed'
# echo $word
changed
# exit
exit
# echo $word
Some important string or data
# echo $0
bash
#
HTH

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

v0.9 fails in pupmode 6

#118 Post by mavrothal »

I see the big warning in v0.9 that in pupmode 6 is experimental, but it simply fails. "Failed to mount /initrd/pup_rw/name.sfs on /initrd/pup_roX" is all I get :cry:
v0.8 with the little addition was working OK...
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

User avatar
shinobar
Posts: 2672
Joined: Thu 28 May 2009, 09:26
Location: Japan
Contact:

Re: v0.9 fails in pupmode 6

#119 Post by shinobar »

mavrothal wrote:I see the big warning in v0.9 that in pupmode 6 is experimental, but it simply fails. "Failed to mount /initrd/pup_rw/name.sfs on /initrd/pup_roX" is all I get :cry:
Thanks mavrothal for the report, but i cannot reproduce your problem.
I tested sfs_load-0.9 with wary-503q on a virtual PC and successfully loaded sfs under PUPMODE=6... :?:
Downloads for Puppy Linux [url]http://shino.pos.to/linux/downloads.html[/url]

mhanifpriatama
Posts: 60
Joined: Sat 22 Jan 2011, 07:50

#120 Post by mhanifpriatama »

Just report. I try in my lucid puppy 520, fresh frugal install. And run.
I would be very happy if can click once, then run the program directly.
Like at http://portablelinuxapps.org

Post Reply