Trash problems (Solved)
Trash problems (Solved)
Right click Trash -> View Summary.
This gives empty list even if there are items in trash.
/usr/local/apps/Trash/AppRun, line 195:
cat /tmp/trashitems | sed -e 's/</?/g' | sed -e 's/>/?/g' > /tmp/trashitems
If deleting above line View Summary works ok. But that line maybe have some meaning.. how to fix it?
Also.. when dragging and dropping any item to Trash, it causes two lines appearing to /tmp/xerrs.log:
/usr/local/apps/Trash/AppRun: line 234: test: -sd: unary operator expected
/usr/local/apps/Trash/AppRun: line 120: [: =: unary operator expected
I am using Lucid 528, but tried also Precise 542 Retro live-CD.
This gives empty list even if there are items in trash.
/usr/local/apps/Trash/AppRun, line 195:
cat /tmp/trashitems | sed -e 's/</?/g' | sed -e 's/>/?/g' > /tmp/trashitems
If deleting above line View Summary works ok. But that line maybe have some meaning.. how to fix it?
Also.. when dragging and dropping any item to Trash, it causes two lines appearing to /tmp/xerrs.log:
/usr/local/apps/Trash/AppRun: line 234: test: -sd: unary operator expected
/usr/local/apps/Trash/AppRun: line 120: [: =: unary operator expected
I am using Lucid 528, but tried also Precise 542 Retro live-CD.
- L18L
- Posts: 3479
- Joined: Sat 19 Jun 2010, 18:56
- Location: www.eussenheim.de/
Re: Trash problems
The meaning is:zephyr2 wrote:Right click Trash -> View Summary.
This gives empty list even if there are items in trash.
/usr/local/apps/Trash/AppRun, line 195:
cat /tmp/trashitems | sed -e 's/</?/g' | sed -e 's/>/?/g' > /tmp/trashitems
If deleting above line View Summary works ok. But that line maybe have some meaning.. how to fix it?.
print the content of file /tmp/trashitems to stream editor sed who has to change each occurance of < to ? and each > to ? and print the result to file /tmp/trashitems
if something does not happen fast enough this results in an empty file.
Doing the same but smarter, -i ...... inline, both string replacements in one sed commandmy fix wrote:#cat /tmp/trashitems | sed -e 's/</?/g' | sed -e 's/>/?/g' > /tmp/trashitems
sed -ie 's/</?/g;s/>/?/g' /tmp/trashitems
Did not happen again after applying above fixzephyr2 wrote:Also.. when dragging and dropping any item to Trash, it causes two lines appearing to /tmp/xerrs.log:
/usr/local/apps/Trash/AppRun: line 234: test: -sd: unary operator expected
/usr/local/apps/Trash/AppRun: line 120: [: =: unary operator expected.
I am using Precise 54
zephyr2 is right -you can't cat out of a file and back into itself at the same time. His correction works (with versions of sed which support the '-i option). sed actually creates a temp file when used with the -i option. Changing the original command to this:
does exactly the same thing.
Code: Select all
cat /tmp/trashitems | sed -e 's/</?/g' | sed -e 's/>/?/g' > /tmp/trashitems~
mv /tmp/trashitems~ /tmp/trashitems
Wow, so people do use the Trash roxapp (or at least try to).
Thanks for actually reporting this.
We already had the same discussion when someone pointed out this bug a year or so ago (I thought it was Barry, or maybe someone commenting on his blog, but I can't find it there now). Of course, the fix was pointed out too, and I figured I should probably try to get a fixed version packaged and included in Puppy, but never got around to it.
I thought I should first check exactly what Barry was using in Puppy (I know it wasn't exactly what I made) and package the update to match it. But I couldn't even find an official Puppy Trash package, so I guess it is hidden away inside something else...
And at the same time I wanted to see if I could tidy up some of the other code, and make it work using just gtkdialog for all the guis, and internationalize it as well (since Technosaurus or someone showed how to do that properly)... all this could be quite an effort for me, as I'm just an ignorant user
Thanks for actually reporting this.
Unfortunately in some circumstances you actually can. It always worked perfectly fine for me in my Puppy install, otherwise I wouldn't have published it like that in the first placeamigo wrote:zephyr2 is right -you can't cat out of a file and back into itself at the same time.
We already had the same discussion when someone pointed out this bug a year or so ago (I thought it was Barry, or maybe someone commenting on his blog, but I can't find it there now). Of course, the fix was pointed out too, and I figured I should probably try to get a fixed version packaged and included in Puppy, but never got around to it.
I thought I should first check exactly what Barry was using in Puppy (I know it wasn't exactly what I made) and package the update to match it. But I couldn't even find an official Puppy Trash package, so I guess it is hidden away inside something else...
And at the same time I wanted to see if I could tidy up some of the other code, and make it work using just gtkdialog for all the guis, and internationalize it as well (since Technosaurus or someone showed how to do that properly)... all this could be quite an effort for me, as I'm just an ignorant user
Do you know a good gtkdialog program? Please post a link here
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
I see that the main problem has been solved thanks to the multiple valid solutions proposed in this thread.
I also noticed that SFR suggested a couple of proposed solutions in another thread:
SFR's suggestion that "Gtkdialog won't mind if there will be < > chars in cat'ted string between <input>cat /tmp/trashitems</input> tags" sounds right to me, although I only did some quick testing.
If that is true, this would seem to be the preferred solution, since filenames containing < and > would then display correctly in the summary window. Of course filenames with those characters should be a rare occurrence, since using those characters in filenames is not good practice. (But it is legal).
disciple, do you remember if you ran into any problems if you didn't translate those characters? Or did you add that line to be cautious, just in case those characters might cause trouble if left untranslated?
Naturally, if there is a known problem when that translation is missing, one of the other solutions would be preferred. Certainly any of the proposed solutions is much better than the status quo, where you may not see any filenames at all.
The main reason for this post is to address the error messages that zephyr2 reported, and one other that I ran into.
to:
Why? If $shortcuts was never set, the test is equivalent to
which is not a valid test.
To fix, change line 234:
to:
Why?
This is a strange one. To the best of my knowledge, there is not now, nor has there ever been an -sd test in bash. Perhaps someone more familiar with bash scripts can let me know if there ever was such a test.
This script goes back to 2005. I didn't look back that far, but I did find a version from 2006, with this line. So it has been there for years if not forever.
I have no idea why that -sd was put there.
But the code works!
It gives that error message, but it works.
At that point in the script, the $1 parameter has already been compared to all of the valid command-line options ("-look", "-summary", etc.), and none were found. So now if there are any command-line arguments, they are the names of files or directories to be deleted. And if there are no arguments, then the trash icon was clicked because the user wants to look in the trash. So this test just determines which of these two actions to take.
Since -sd is not a valid test, bash just assumes that it is a string. So if there are no arguments
is equivalent to
which is a valid test, and exits true (0) since the string is not empty. So when the script then compares the exit status with "0", it correctly takes the branch that shows the trash.
One thing here confused me at first. Since $@ is contained inside quotation marks, I would have thought that the equivalent line in this case would be:
which is not a valid test. But a look at the bash man page explained why that was not the equivalent:
which is not a valid test, and exits false (2) since it is invalid. So when the script compares the exit code to "0", it correctly takes the branch that moves the file(s) to the trash.
So, the original line, despite being invalid in bash and causing an error message, seems to work as intended.
My change simply does the same thing with valid code.
There is a similar bug in template/temp-AppRun, which is the template for the scripts that are used to restore items. Restoring an item caused an error message like this:
to:
By the way, I am assuming that this application was never intended to be used from the command line. Although it works from the command line, it is far from bullet-proof in that case. From the command line, one can pass it fictitious filenames to move to the trash, and it will happily make entries in the trash. And, from the command line, one needs to pass the full pathname (e.g, /root/my-documents/testfile.txt), not just the filename (e.g., testfile.txt) -- if not, the file cannot be restored.
Since the intention is for files to be moved to the trash by drag-and-drop, there should not be a problem with fictitious filenames or files without the full pathname. So I've not bothered to address either of those issues here.
There is one other bug that I am aware of. Trash likes to make a rather annoying sound when trashing an item. But since some folks might consider this a feature, I have not addressed this issue either.
http://bkhome.org/fossil/woof2.cgi/dir? ... apps/Trash
I also noticed that SFR suggested a couple of proposed solutions in another thread:
Apparently 01micko has used one of SFR's proposals in the latest Slacko beta:[url=http://www.murga-linux.com/puppy/viewtopic.php?p=679251#679251]In the Slacko-5.4 feedback and bug reports thread[/url], SFR wrote:doesn't work as it supposed to, I guess.Code: Select all
cat /tmp/trashitems | sed -e 's/</?/g' | sed -e 's/>/?/g' > /tmp/trashitems
Proposed fixes:
- To append those two sed commands to the above "long sed parade"
- Actually Gtkdialog won't mind if there will be < > chars in cat'ted string between <input>cat /tmp/trashitems</input> tags, so maybe delete the line completely..? (works for me)
SFR's second proposed fix matches the modification that zephyr2 used successfully.
SFR's suggestion that "Gtkdialog won't mind if there will be < > chars in cat'ted string between <input>cat /tmp/trashitems</input> tags" sounds right to me, although I only did some quick testing.
If that is true, this would seem to be the preferred solution, since filenames containing < and > would then display correctly in the summary window. Of course filenames with those characters should be a rare occurrence, since using those characters in filenames is not good practice. (But it is legal).
disciple, do you remember if you ran into any problems if you didn't translate those characters? Or did you add that line to be cautious, just in case those characters might cause trouble if left untranslated?
Naturally, if there is a known problem when that translation is missing, one of the other solutions would be preferred. Certainly any of the proposed solutions is much better than the status quo, where you may not see any filenames at all.
The main reason for this post is to address the error messages that zephyr2 reported, and one other that I ran into.
To fix, change line 120:zephyr2 wrote:/usr/local/apps/Trash/AppRun: line 120: [: =: unary operator expected
Code: Select all
Had desktop shortcut? = `if [ $shortcuts = "true" ]; then echo yes; else echo no; fi`" > "$HOME/.Trash/$FileName-$$/Info"
Code: Select all
Had desktop shortcut? = `if [ "$shortcuts" = "true" ]; then echo yes; else echo no; fi`" > "$HOME/.Trash/$FileName-$$/Info"
Code: Select all
[ = "true" ]
(If you move two items to the trash, you instead get "binary operator expected", and three or more items gives you "too many arguments".)zephyr2 wrote:/usr/local/apps/Trash/AppRun: line 234: test: -sd: unary operator expected
To fix, change line 234:
Code: Select all
test -sd "$@"
Code: Select all
test -z "$*"
This is a strange one. To the best of my knowledge, there is not now, nor has there ever been an -sd test in bash. Perhaps someone more familiar with bash scripts can let me know if there ever was such a test.
This script goes back to 2005. I didn't look back that far, but I did find a version from 2006, with this line. So it has been there for years if not forever.
I have no idea why that -sd was put there.
But the code works!
It gives that error message, but it works.
At that point in the script, the $1 parameter has already been compared to all of the valid command-line options ("-look", "-summary", etc.), and none were found. So now if there are any command-line arguments, they are the names of files or directories to be deleted. And if there are no arguments, then the trash icon was clicked because the user wants to look in the trash. So this test just determines which of these two actions to take.
Since -sd is not a valid test, bash just assumes that it is a string. So if there are no arguments
Code: Select all
test -sd "$@"
Code: Select all
test -sd
One thing here confused me at first. Since $@ is contained inside quotation marks, I would have thought that the equivalent line in this case would be:
Code: Select all
test -sd ""
When there are are one or more command line arguments, the equivalent line would be something like:Bash Reference Manual: [url=http://www.gnu.org/software/bash/manual/bash.html#Special-Parameters]Special Parameters[/url] wrote:When there are no positional parameters, "$@" and $@ expand to nothing (i.e., they are removed).
Code: Select all
test -sd "testfile.txt"
So, the original line, despite being invalid in bash and causing an error message, seems to work as intended.
My change simply does the same thing with valid code.
There is a similar bug in template/temp-AppRun, which is the template for the scripts that are used to restore items. Restoring an item caused an error message like this:
To fix, change line 141 in template/temp-AppRun:/root/.Trash/testfile.txt-32174/AppRun: line 141: test: -sd: unary operator expected
Code: Select all
test -sd "$@"
Code: Select all
test -z "$*"
Since the intention is for files to be moved to the trash by drag-and-drop, there should not be a problem with fictitious filenames or files without the full pathname. So I've not bothered to address either of those issues here.
There is one other bug that I am aware of. Trash likes to make a rather annoying sound when trashing an item. But since some folks might consider this a feature, I have not addressed this issue either.
Yes. It is included in Woof:disciple wrote:I thought I should first check exactly what Barry was using in Puppy (I know it wasn't exactly what I made) and package the update to match it. But I couldn't even find an official Puppy Trash package, so I guess it is hidden away inside something else...
http://bkhome.org/fossil/woof2.cgi/dir? ... apps/Trash
That original empty-list-problem began to wonder me when I was trying to translate Trash in my home language.
Latest Trash I found was version 0.3.3. I changed it so that it could be translated. I am not programmer at all, so changes may look terrible and it's maybe better not to install this at all. However, I have used this translated version for a week now and it should work like original with above fixes (L18L and npierce). I am using Lucid 528, not tested in any other versions.
There is .pot file included, it goes to folder /usr/share/doc/nls/trash.
Latest Trash I found was version 0.3.3. I changed it so that it could be translated. I am not programmer at all, so changes may look terrible and it's maybe better not to install this at all. However, I have used this translated version for a week now and it should work like original with above fixes (L18L and npierce). I am using Lucid 528, not tested in any other versions.
There is .pot file included, it goes to folder /usr/share/doc/nls/trash.
- Attachments
-
- Trash-with-gettext.pet
- (24.27 KiB) Downloaded 637 times
- L18L
- Posts: 3479
- Joined: Sat 19 Jun 2010, 18:56
- Location: www.eussenheim.de/
Trash
... and I have been using it to make a translation to German.zephyr2 wrote:... I changed it so that it could be translated. ...
Just 2 notes:
1,
installing the pet was no good idea for me because my German AppInfo.xml was gone.
2,
trash.pot is NOT necessary because momanager can create it
I attach (just for convenience of everybody) /usr/local/apps/Trash/AppRun
internationalized by zephyr2 (version 0.4 )
----
edited 2013-02-15 10:30 GMT+1
Attachment deleted
BarryK has fixed it in woof, see (and download from)
http://bkhome.org/blog2/?viewDetailed=00125
A bug that I noticed not so long ago...
When an item gets trashed and then the directory where it was also gets removed (later), 'Restore Trashed Item' function doesn't work properly and such a file/folder just vanishes (mv -f item non_existent_path).
Well, simple mkdir -p destdir before mv would do the job, but then if the missing path is, for example /mnt/some_unmounted_device/, there might be a mess later...
My proposal is to display a confirmation dialog where a user can see what path is going to be recreated, so can decide if (s)he really wants to restore an item right there (if not, one can always just extract an item from Trash manually and put elsewhere).
The relevant part of code was amended from:
to:
What do you think?
Perhaps it's not the best solution, but surely better than loosing a file.
Modified /usr/local/apps/Trash/template/temp-AppRun script attached (real .gz).
EDIT:
I forgot that if a device was mounted and unmounted, its root directory stays in /mnt/ anyway.
So, in case if an item is going to be restored to /mnt/... a warning window will pop up (see screenshot).
Code above and attachment updated.
Greetings!
When an item gets trashed and then the directory where it was also gets removed (later), 'Restore Trashed Item' function doesn't work properly and such a file/folder just vanishes (mv -f item non_existent_path).
Well, simple mkdir -p destdir before mv would do the job, but then if the missing path is, for example /mnt/some_unmounted_device/, there might be a mess later...
My proposal is to display a confirmation dialog where a user can see what path is going to be recreated, so can decide if (s)he really wants to restore an item right there (if not, one can always just extract an item from Trash manually and put elsewhere).
The relevant part of code was amended from:
Code: Select all
# Restore the item.
mv -f "$APPDIR/Files/$FileName" "PATH"
Code: Select all
# Restore the item.
# Check if destination path is in /mnt and warn a user
restore_path="`dirname "PATH"`"
restore_name="`basename "PATH"`"
if [ "`echo "PATH" | grep '^/mnt/'`" ]; then
pupdialog --title "$(gettext 'Caution')" --yes-label "$(gettext 'Restore')" --no-label "$(gettext 'Cancel')" --yesno "$restore_name $(gettext 'will be restored to: ')$restore_path
$(gettext 'Make sure that the appropriate device is mounted.')"
[ $? -ne 0 ] && exit
fi
# If dest dir doesn't exist, ask to create one
if [ ! -d "$restore_path" ]; then
pupdialog --title "$(gettext 'Confirm Action')" --yes-label "$(gettext 'Create')" --no-label "$(gettext 'Cancel')" --yesno "$(gettext 'Destination directory: ')$restore_path
$(gettext 'does not exist! Create it?')"
if [ $? -eq 0 ]; then
mkdir -p "$restore_path"
else
exit
fi
fi
mv -f "$APPDIR/Files/$FileName" "PATH"
Perhaps it's not the best solution, but surely better than loosing a file.
Modified /usr/local/apps/Trash/template/temp-AppRun script attached (real .gz).
EDIT:
I forgot that if a device was mounted and unmounted, its root directory stays in /mnt/ anyway.
So, in case if an item is going to be restored to /mnt/... a warning window will pop up (see screenshot).
Code above and attachment updated.
Greetings!
- Attachments
-
- scrsht.png
- (11.73 KiB) Downloaded 847 times
-
- temp-AppRun.gz
- Unpack and copy to /usr/local/apps/Trash/template/
- (2.28 KiB) Downloaded 578 times
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]
[b][color=green]Omnia mea mecum porto.[/color][/b]
That sounds like a great idea, although to futureproof it or allow for people with different systems it should really check for /media and /var/run as well as /mnt. But even that wouldn't be enough, because things can be manually mounted anywhere...
It might be better to check when trashing it whether the path is in the same filesystem as the Trash, and record that fact.
But if we're going to go to the effort to do that, we might as well implement proper per-device Trash, as we discussed in the "discussion document" thread. I did think what we would need to do is send the trashed file to a Trash at the top of its filesystem, and then when we check the Trash, check every filesystem for a Trash and collate the results. I guess this is a bit hacky, but now I'm wondering if we couldn't just symlink anything trashed on an external filesystem into the main Trash. The problems would be:
1. ignoring the symlink when the external filesystem isn't mounted (shouldn't be too hard), and
2. when looking at the trash you wouldn't see anything in a Trash on an external filesystem which was trashed from another Puppy install or by another Puppy user.
Does anyone have any thoughts on this?
It might be better to check when trashing it whether the path is in the same filesystem as the Trash, and record that fact.
But if we're going to go to the effort to do that, we might as well implement proper per-device Trash, as we discussed in the "discussion document" thread. I did think what we would need to do is send the trashed file to a Trash at the top of its filesystem, and then when we check the Trash, check every filesystem for a Trash and collate the results. I guess this is a bit hacky, but now I'm wondering if we couldn't just symlink anything trashed on an external filesystem into the main Trash. The problems would be:
1. ignoring the symlink when the external filesystem isn't mounted (shouldn't be too hard), and
2. when looking at the trash you wouldn't see anything in a Trash on an external filesystem which was trashed from another Puppy install or by another Puppy user.
Does anyone have any thoughts on this?
Do you know a good gtkdialog program? Please post a link here
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
Hey Disciple
Yeah, would be really nice to have it this way...
I just remembered that there's a short bash script (used by 'Trash-plugin' for SpaceFM):
https://code.google.com/p/bashscripts/s ... runk/trash
It might shed some light on how to implement all that stuff you've mentioned.
BTW, I don't know if I'm doing something wrong or it's implemented this way, but action like '--delete' '--restore' or '--info', require full path to the main trashcan, e.g.:
trash --restore /root/.local/share/Trash/files/sometestfile
but the good thing is that, as mentioned above, it holds there also links to external trashcans, so it's not a big deal.
But it's important to keep this in mind, because I did use (unnecessarily - there's also '--empty' command) 'trash --delete *' a moment ago and deleted my whole $HOME (/root/*) dir!
Luckily PUPMODE=13 + save_on_demand mod in rc.shutdown saved my day (again).
Greetings!
Yeah, would be really nice to have it this way...
I just remembered that there's a short bash script (used by 'Trash-plugin' for SpaceFM):
https://code.google.com/p/bashscripts/s ... runk/trash
It might shed some light on how to implement all that stuff you've mentioned.
Alas, personally I don't feel strong enough to modify ROX-Trash like that...trash.readme wrote:If the item to be trashed is on a different mountpoint than the trashcan (different partition/drive), the script will create trash directories where this filesystem is mounted and store trashed file there. It aslo create links to the main trashcan so that all trashed items can be viewed in one place. For example, trashcan=/home/user/.local/share/Trash/files which is mounted at /home. You trash a file /media/usbdrive/somefile which is mounted at /media/usbdrive. The script will create /media/usbdrive/.Trash-user/{files,info} directories and somefile will be moved into this directory. It also creates a link in the main trashcan to somefile so that somefile can also be seen here.
BTW, I don't know if I'm doing something wrong or it's implemented this way, but action like '--delete' '--restore' or '--info', require full path to the main trashcan, e.g.:
trash --restore /root/.local/share/Trash/files/sometestfile
but the good thing is that, as mentioned above, it holds there also links to external trashcans, so it's not a big deal.
But it's important to keep this in mind, because I did use (unnecessarily - there's also '--empty' command) 'trash --delete *' a moment ago and deleted my whole $HOME (/root/*) dir!
Luckily PUPMODE=13 + save_on_demand mod in rc.shutdown saved my day (again).
Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]
[b][color=green]Omnia mea mecum porto.[/color][/b]
Well, the poor-mans method I'm suggesting with symlinks should actually be pretty simple, so I am happy to do it if people think it is a good idea.Alas, personally I don't feel strong enough to modify ROX-Trash like that...
Do you know a good gtkdialog program? Please post a link here
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
a newer way of doing Trash functions in ROX
Sorry for necro-bumping here, but...while fiddling with xfce in Fedora I discovered that, besides the Rox Trash applet which dvm (Dan Van Wormer) originally wrote for Puppy Linux in 2005...there exists another Rox Trash applet, Rox Trasher Master. It differs from the traditional Puppy Rox Trash in that, like Thunar, it writes to $HOME/.local/share/Trash, and creates "trash:///files" and "trash:///info" subdirectory entries the same way Thunar does. Therefore a file which is sent to Trash by Rox can be restored by Thunar. A file sent to trash by Thunar can't be restored by Rox though, because the restorative powers of this Rox Trasher Master (invoked as AppRun --look) rely upon entries in a special restore subdirectory in /usr/local/apps/Trash. Thunar, when it moves a file to Trash, does not create an entry in Rox Trasher Master's restore subdirectory, so Rox Trasher Master does not know about files which were moved to Trash by Thunar. It also has no way of knowing when a file is restored by Thunar, therefore the restore subdirectory does tend to growandgrow. So I've commented-out all the create-and-interrogate-and-restore-from code in my local copy of Rox Trasher Master's AppRun, leaving only the Send to Trash sections, and I also eliminated the "are you sure" dialog, and now I can use Rox for sending items to Trash, which I can restore from Thunar.
This new Rox trash is immensely handy in a mixed Rox+Thunar environment. Probably equally handy when used with any other file manager which does Trash the xdg way too.
Have a look:
https://github.com/fgb/rox-trasher
Disclaimer: I'm starting Thunar (in Fedora) by the following script, which is necessary in order for Thunar to see trash:/// when Thunar is run as root.where the long alphanumeric string is the machine ID according to dbus. In Fedora this is found in $HOME/.dbus/session-bus, in the first line of the only file which is resident therein. Been awhile since I used Puppy, but when I look in my Quirky /root/.dbus/session-bus I see a lot of files, perhaps because I've transferred the install back and forth to very many machines. You'd want to look at the first line of the most recent one.
This new Rox trash is immensely handy in a mixed Rox+Thunar environment. Probably equally handy when used with any other file manager which does Trash the xdg way too.
Have a look:
https://github.com/fgb/rox-trasher
Disclaimer: I'm starting Thunar (in Fedora) by the following script, which is necessary in order for Thunar to see trash:/// when Thunar is run as root.
Code: Select all
#!/bin/sh
# /usr/bin/thunar-start-script
if [[ $EUID -ne 0 ]]; then
exec /usr/bin/thunar "$@"
else
dbus-launch --autolaunch 36cfcdcd4f69479bb01ea212907a152e --exit-with-session /usr/bin/thunar "$@"
fi
“A wise man can learn more from a foolish question than a fool can learn from a wise answer.†--Bruce Lee
Whatever you come up with.
Make sure it gets into Woof-CE
I think this is where it is in Woof-CE, but if not. It is someplace in Woof-CE.
https://github.com/puppylinux-woof-CE/w ... apps/Trash
Make sure it gets into Woof-CE
I think this is where it is in Woof-CE, but if not. It is someplace in Woof-CE.
https://github.com/puppylinux-woof-CE/w ... apps/Trash
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
Why would you want a trash with no restore capability in woof?
Do you know a good gtkdialog program? Please post a link here
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
ROX-Trasher would not be suitable for woof until...
I agree with disciple, this is not ready for woof. It would become ready for woof only if an appropriate matching daemon could be composed which monitors the ~/.local/share/Trash directory and, whenever there's a change, enforces the same change in the /usr/local/apps/Trash/.restore-all and ~/.config/ROX-Trasher subdirectories of this new trash facility. And vice-versa.
But ROX-Trasher is still useful when in a mixed rox-and-thunar environment, provided thunar can be started from a script as described in my post above.
But ROX-Trasher is still useful when in a mixed rox-and-thunar environment, provided thunar can be started from a script as described in my post above.
“A wise man can learn more from a foolish question than a fool can learn from a wise answer.†--Bruce Lee