Solved - everything seems to work now. I've updated the code here.
This is an update to the Trash ROXapp so that it will work with files that have spaces in their name or path. Please test.
I'll also do a version that shows you an item in the trash when you click on it, instead of offering to restore it, and that has new entries on the context menu to delete the item, and to view the item.---Edit - this new version is in the next post---

--------------------------
Original post
I'm trying to modify the Trash ROXapp so that it will work with files that have spaces in their name or path (This is one thing that really annoys me in Puppy, and I think it would be a great improvement for newbies). It almost all works, but when I try to restore an item with spaces in its name (it is OK with spaces in the path) I get something like this:

Code:

mv: cannot stat `/root/.Trash/2 3-3565/1': No such file or directory

I can't figure out where the /1 is coming from - I could just strip it off, as it always seems to be /1, but that doesn't seem very proper. I don't really know Bash, and I'm not much of a programmer, so can anyone fix the code please?
-------------------------

We should probably also add a "delete this item" feature, as at the moment if a user goes into the trash and decides the want to delete the only item in there, they're likely to delete it the way you normally delete things, rather than emptying the trash, in which case the trash icon does not get changed to the empty one.

I've attached a .pet below, or here is the [updated] code:
/usr/local/apps/Trash/AppRun:

# If they chose to "Quickly Empty the Trash".
elif [ "$1" = "-empty-quick" ]
then

rm -r /root/.Trash/*

EmptyIcon

PlaySound

else

# Check to see if they clicked on the application or sent a file or directory to be deleted.
test -sd "$@"
if [ "$?" = "0" ]
then

# If they just clicked on the icon.
exec rox /root/.Trash

else

# If they sent something to the trash can.
for m in "$@"
do

# Test to see if the item is a symbolic link.
if [ -h "$m" ]
then

# Write the confirmation message.
MSG=`which gxmessage` || MSG=xmessage
$MSG -buttons "Yes:21,No" -center -geometry 550x90 -title "Confirm Action" "The item $m is a Symbolic Link.
This will move the Symbolic Link to the Trash and leave the original item alone.
Do you want to continue?"

# If they chose to cancel.
[ $? -eq 21 ] || exit

fi

match=`grep ">$m<" /root/Choices/ROX-Filer/PuppyPin`

# Test $match to see if the item had a link to it on the pinboard.
test "$match"
if [ "$?" = "0" ]
then

# Write the confirmation message.
MSG=`which gxmessage` || MSG=xmessage
$MSG -buttons "Yes:21,No" -center -geometry 560x90 -title "Confirm Action" "There is one or more Desktop shortcuts pointing to $m
This will move the original item to the Trash and remove the shortcut(s) from the Desktop.
Do you want to continue?"

New version as anticipated above:
Works with spaces in filename or path of course.
Opens a trashed item if you click on it, instead of offering to restore it.
Additional context menu options, "Permanently Delete Item" and "Open Item".

BTW. Nathan has modified the original Trash for a multi-user environment, and has some other interesting plans for new features.

----------------------------
Wait a minute - I'll just go and test in a Puppy with the new Rox.
---------------------------
Yes, good, it seems to all work great

Here's another version, just with an added function to "View item", that opens the appdir in a new window. ---You might not want it with the ROX menu structure in Puppy - I'm using Grafpup 104 long term, and it's much more convenient than searching through the menu for the "look inside" option---Edit-Nonsense---the menu structure is identical---

The "open with" menu is so important in Puppy that it would be quite good to have an "open item with" feature, but that's just getting too complicated for me, so this is the next best thing.

You seemed to have an extra "fi" at the end of each of the scripts in the last version (haven't checked the new one yet)._________________What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

Ah - you are right, but that was not me. It was there before I touched them. I guess someone could have removed them in recent Puppies though - I didn't actually check if the trash is exactly the same in them, just looked, and everything claimed to be the same version, so I assumed it was (I did check that spaces didn't work though - that's why I looked to see if there was a new version).

I've just noticed that strange things happen if you restore a file and tell it to overwrite a directory with the same name, or vice versa. I doubt that my changes have caused it, but I don't have time to check it out at the moment.

I don't know why I thought the menu structure was different in ROX now - it is exactly the same, so I think it would be good to use the third version. It just seems a bit more user friendly.

Ah - you are right, but that was not me. It was there before I touched them.

I'm not sure... I think when you added the extra options you combined a couple of "if"s (the first being the "test -sd" one)._________________What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

We should probably add an additional check when the user restores a file, for either the file being restored or the file being overwritten being a directory, in which case I don't know - rename one of them? Prevent the file being restored?
I think what happens at the moment is if either of them is a directory, you just lose whatever you're trying to restore, unless e.g. I'm restoring a file named "ted" and where it should be restored to there is an existing directory named "ted", without a file or directory named "ted" inside it, in which case the file gets restored into the folder.

We should probably either just give a warning to change the name of something, and refuse to restore the item, or first remove the item to be overwritten, and then restore the item to be restored.

EDIT - Maybe it would even be best to trash the file that would be overwritten.

Wow, this is great. I've been a little busy with my new job, house, and all. If I had known you were working on the Trash, I would have helped out. I've just been reading Barry's new page and haven't had much time to spend on the forum. These are all things I was thinking of improving on. The other thing I was thinking of doing was re-writing it in murgaLua. Basically I wanted to eliminate xmessage and give it a much better look. Good job though.
Dan

OK - I just noticed another problem with the current setup - if you trash an AppInfo.xml or AppRun file, then you lose it because it gets replaced by the one generated to operate the roxapp for the trashed item. If you don't follow me, try it and see what happens.

I think the simplest fix for this would be to change the trash so that instead of putting the trashed item directly in the roxapp, it gets put in a folder with a fixed name - e.g. if I trash a file called 2007-September.txt, instead of getting put in ~/.Trash/2007-September.txt-6926/ it will now get put in ~/.Trash/2007-September.txt-6926/trashed-item/

This should be fairly straightforward, but I think there are a couple of shortcuts we've used in the code that will need to be replaced by some more advanced script that I'd need to research as I know very little BASH. I don't really have any time to do this right now, so if anyone else wants to, feel free.

dvw86 - if it was re-done in murgaLua, would it still be really fast?

If anybody does do anything with it, they might want to also re-look at what would be the best way to handle overwritten items when restoring. I like what I did, but it will cause a problem if you restore something and overwrite a really big item that is on a different partition (you might run out of space in your pup_save when moving the item that is being overwritten to the Trash).
Also, if you keep it my way, I don't think I changed the message to indicate that it is being Trashed, rather than simply overwritten.
------------------------------
BTW if anyone reads this and is concerned about backward compatibility, don't worry - because of the way it works, any updates to the trash app only affect new trashed items, and old ones behave the same way they did when they were trashed.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum