Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Recycle File
#31
(02-28-2026, 07:42 PM)NakedApe Wrote: Yes, justsomeguy has an Intel-based Mac while mine is an M2 ARM-based Mac, which is about four years old. Yesterday I looked up "mv" and "trash" and I coulda sworn it said that the Mac/Unix terminal command trash was introduced in 2023, but now I can't find that. And what I did find says that the trash command is non-native and requires installing with third-party software. Wha?!  I just tried it again and it works fine, so I'm fairly flummoxed with this.

I just created a dummy file and used Terminal to "trash /users/me/desktop/crap.pages" and the file was successfully moved to the trash can. Maybe Sam @a740g can shine some light on this? 

Here's what I've found concerning the command:

Quote:An official, native trash command-line tool was introduced to macOS starting with macOS 15 Sequoia.  While the first version of macOS to support ARM-based Apple Silicon was macOS 11 Big Sur (released November 2020), it did not include a built-in command-line utility for moving files to the Trash; users previously relied on third-party tools like brew install trash or shell aliases for rm.
Timeline of the trash Command:
-- macOS 11 Big Sur (2020): First ARM64 support, but no native trash CLI tool.
-- macOS 15 Sequoia (2024): Introduction of the official Apple-provided trash command.
Functionality: The native command allows users to move files to the system Trash folder via Terminal without permanently deleting them (unlike the rm command).

So it seems trash will work on newer, more modern machines, but not on older versions.  Now if I can sort out why mv won't work on your system.  LOL!  Looks like there's still more digging to do on this mystery.
Reply
#32
@NakedApe

Here's what i found out with why mv might not work properly on your system. Reason #1 sounds like it might be an issue, if it's a permission thing which is off by default.



While there isn't an "ARM-specific" block, modern macOS versions (which all ARM Macs run) have strict security protocols that often block the Terminal from interacting with the Trash folder.

Common reasons why mv file ~/.Trash/ fails:

1. Missing Full Disk Access
By default, the Terminal does not have permission to modify "protected" folders like ~/.Trash/, leading to "Operation not permitted" errors.

Fix: Go to System Settings > Privacy & Security > Full Disk Access and toggle the switch for Terminal to ON.

2. Incorrect Trash Path for External Drives
Each drive on a Mac has its own hidden trash folder. If the file you are moving is on an external drive, ~/.Trash/ (which is on your internal startup disk) might not be the correct destination for a simple "move".

Fix: For files on external volumes, the path is usually /Volumes/[DriveName]/.Trashes/[UserUID]/.
3. Folder Ownership or Corruption
Sometimes the .Trash directory itself has incorrect permissions or has become corrupted.

Verify: Run ls -ld ~/.Trash to see the permissions. It should be owned by your username with rwx permissions.
Fix: If it's missing or broken, you can recreate it by running mkdir ~/.Trash (though you may need to delete a corrupted one first with sudo rm -rf ~/.Trash).

4. Better Alternatives for CLI Deletion
Moving files to the Trash via mv is technically a "move," not a "delete." Most power users prefer these methods:
Permanent Delete: Use rm -rf [filename] to delete immediately without the Trash.
Third-Party Tools: Install trash via Homebrew (brew install trash), which allows you to run trash [filename] to safely send files to the system bin exactly like the Finder does.
Reply
#33
Okay! Nice job getting that info, @SMcNeill. 

1. So I checked Privacy & Security > Full Disk Access and, while Terminal had full permission, QB64pe did not. It had never been an issue because I'd never tried to move a file to the Trash before using a QB program. I've KILLed plenty of files - that was okay with the OS - but for some reason accessing the Trash requires full disk access.

2. I tried using your latest Recycle Bin prog on page 3 and it still didn't work, however, the last one above by @justsomeguy works just fine using the "mv" command. Hurrah!  Wink  I guess I never tried using the mv command in a Terminal window yesterday - I only used it in the QB progs.

SO, this should be universal for Macs as long as the QB64pe application is given FULL disk access:

            cmd$ = "mv " + Chr$(34) + file$ + Chr$(34) + " ~/.Trash/"
            Shell cmd$
Reply
#34
Oh ho!  Finally a universal approach!  I’ll swap to mv as default,  check for file existence afterwards, and if the file exists use MessageBox to prompt the user checks permission states.

That should cover our bases completely.
Reply
#35
@NakedApe @justsomeguy

Updated the first post to use mv exclusively, and to offer a messagebox when it fails. Can you guys give this one last try for us and make certain I dotted my i's and crossed my t's properly? Make certain no syntax was off, or some small type who makes it unusable for everyone. Wink
Reply
#36
@SMcNeill I fixed a few typos, but it seems to work on my machine. Good Job Steve!

Code: (Select All)
SCREEN _NEWIMAGE(800, 600, 32)

OPEN "MyFile.txt" FOR OUTPUT AS #1
PRINT #1, "Test:" + DATE$ + " " + TIME$
CLOSE
PRINT "File created called MyFile.txt"

Recycle "MyFile.txt"
PRINT "MyFile.txt should now be recycled and in the Recycle Bin, instead of just erased permanently."
PRINT "Check your recycle bin to see if it exists there and contains a simple message of 'Test'."
END

SUB Recycle (file$)
  IF _FILEEXISTS(file$) THEN
    $IF WIN THEN
            ps$ = "powershell -NoLogo -NoProfile -Command "
            ps$ = ps$ + Chr$(34) + "Add-Type -AssemblyName Microsoft.VisualBasic; "
            ps$ = ps$ + "[Microsoft.VisualBasic.FileIO.FileSystem]:eleteFile('"
            ps$ = ps$ + file$
            ps$ = ps$ + "','OnlyErrorDialogs','SendToRecycleBin')" + Chr$(34)
            Shell _Hide ps$
    $ELSEIF MAC THEN
            Shell _Hide "mv " + Chr$(34) + file$ + Chr$(34) + " ~/.Trash/"
            If _FileExists(file$) Then 'a back up second method as per here --> https://www.macterminal.cc/answers/mv-command-examples
                message$ = "File failed to move to trash folder.  Possible reasons for this are:" + Chr$(10)
                message$ = message$ + Chr$(10)
                message$ = message$ + "1. Missing Full Disk Access" + Chr$(10)
                message$ = message$ + "By default, the Terminal does not have permission to modify 'protected' folders like ~/.Trash/, leading to 'Operation not permitted' errors.  "
                message$ = message$ + Chr$(10)
                message$ = message$ + "Fix: Go to System Settings > Privacy & Security > Full Disk Access and toggle the switch for Terminal to ON." + Chr$(10)
                message$ = message$ + Chr$(10)
                message$ = message$ + Chr$(10)
                message$ = message$ + "2. Incorrect Trash Path for External Drives" + Chr$(10)
                message$ = message$ + "Each drive on a Mac has its own hidden trash folder. If the file you are moving is on an external drive, ~/.Trash/ (which is on your internal startup disk) might not be the correct destination for a simple 'move'." + Chr$(10)
                message$ = message$ + Chr$(10)
                message$ = message$ + "Fix: For files on external volumes, the path is usually /Volumes/[DriveName]/.Trashes/[UserUID]/." + Chr$(10)
                message$ = message$ + Chr$(10)
                message$ = message$ + Chr$(10)
                message$ = message$ + "3. Folder Ownership or Corruption" + Chr$(10)
                message$ = message$ + "Sometimes the .Trash directory itself has incorrect permissions or has become corrupted." + Chr$(10)
                message$ = message$ + Chr$(10)
                message$ = message$ + "Verify: Run ls -ld ~/.Trash to see the permissions. It should be owned by your username with rwx permissions." + Chr$(10)
                message$ = message$ + "Fix: If it's missing or broken, you can recreate it by running mkdir ~/.Trash (though you may need to delete a corrupted one first with sudo rm -rf ~/.Trash)." + Chr$(10)
                _MessageBox "File failed to move to trash", message$, "info"
            End If
    $ELSE
      'Assume Linux-like environment with gio available
      SHELL _HIDE "gio trash " + CHR$(34) + file$ + CHR$(34)
    $END IF
  END IF
END SUB
Reply
#37
Updated with your corrected version.  Unless someone has something new to add, or something that doesn't work, it looks like we finally have a definitive version up and available for anyone to make use of to move files to the recycle bin, rather than deleting them permanently with KILL.  

Thanks for your help with this guys.  It's appreciated.  Wink
Reply
#38
As a complete aside, I also learned the difference between single and double quotes on Mac, and how they work with command line usage.  You guys might be interested to learn this tidbit as well:

Double Quotes allow for substitution inside them.
Single Quotes are for literal raw and unchanging text inside them

So for example (and I'm just going to pseudocode this as I'm not good enough with applescript to claim this is anywhere near right; it's just to showcase the design philosophy):

In terminal:

FOO "whatever$"  <-- this would let you substitute the value for whatever$ into that.  So if whatever$ is a variable holding qb64pe then you would FOO "qb64pe"

FOO 'whatever$'  <-- this does no substitutions and is processed directly as FOO 'whatever$'.

Double Quotes allow for substitution for variables and such, single quotes just keeps literal text grouped together.

That's a fairly important distinction sometimes when scripting, so you guys might want to store that little tidbit of syntax knowledge in the back of your minds if you didn't know it.  I certainly didn't!  At least not until I started digging into mac scripting and such more for this little command!
Reply
#39
Steve, I tried your latest version on a 2014 Intel Mac (that doesn't smell like BO and cigarettes) and my 2023 M2 Mac. Success with both! In your explanations for possible file transfer failures, you should probably also mention the issue I had in reason #1. "By default, neither the Terminal nor QB64pe has permission to modify 'protected' folders..." or something like that. 

Otherwise, well done. Happy to help out.  Smile
Reply
#40
@NakedApe 

I was going to ask about that as it just seems odd to me, and I'd just forgot to.  Seems like giving permission to QB64PE wouldn't change the permissions on the EXE which it generates.  Shouldn't you need to give permission to the created file?  Or are you giving permission to the QB64PE *folder*?

Exactly what the heck did you change for it to work?  If it was QB64PE, can someone explain to me how the heck that permission gets inherited down to the EXE files we create?  As you're describing it, or as my brain is interpreting that description, it doesn't make a whole lot of sense to me right now.
Reply


Forum Jump:


Users browsing this thread: