:hardcopy not launching Preview

[Kenneth R. Beesley]

I've been using MacVim for years, but just recently I've noticed that when I

invoke :hardcopy, either directly or through the pulldown File > Print, it's not

launching Preview (which allows you to select the printer, choose the number of 

copies to print, etc.).  Even more mysterious, it seems to launch Preview some

of the times I try it.  I tried updating both my MacOS and did a fresh 'brew

install macvim".  No resolution yet.

Any help would be much appreciated.  

Ken

[Kenneth R. Beesley]

I'm on a new-this-year MacBook Pro, running Century 13.4.1.

[Yongwei Wu]

I can reproduce this behaviour on Ventura.

I would suggest a workaround. You may use ":TOhtml", and then print
the HTML file from a browser.

--
Yongwei Wu
URL: http://wyw.dcweb.cn/

[Kenneth R. Beesley]

Many thanks for the :TOhtml suggestion.

I now find that "Build-in printing" using :hardcopy is listed under

"16.  Known bugs/missing features" in the MacVim Reference Manual.

[Yongwei Wu]

Actually it is not a bug of MacVim.

Using techniques described in

https://vi.stackexchange.com/questions/6887/where-does-macvim-send-its-printed-files

I have located the file output by Vim. Opening the file by Preview
does not succeed. A search confirmed this:

https://www.macrumors.com/2022/10/25/macos-ventura-preview-app-drops-postscript-support/

Anyway, even the result from ps2pdf does not look satisfying to me.
TOhtml has always been a better solution to me.

On Thu, 29 Jun 2023 at 11:58, Kenneth R. Beesley <krbe...@gmail.com> wrote:
>
> Many thanks for the :TOhtml suggestion.
>
> I now find that "Build-in printing" using :hardcopy is listed under
> "16. Known bugs/missing features" in the MacVim Reference Manual.
>
> On Wednesday, June 28, 2023 at 8:40:24 PM UTC-6 Yongwei Wu wrote:
>>
>> I can reproduce this behaviour on Ventura.
>>
>> I would suggest a workaround. You may use ":TOhtml", and then print
>> the HTML file from a browser.

[Yongwei Wu]

Anyway, I created a solution.

Assuming you have ps2pdf installed (Homebrew ghostscript has it). You can add a vim_preview file:

#!/bin/sh
psfile=$1
pdffile=`echo $psfile|sed -E 's/(\.ps)?$/\.pdf/'`
ps2pdf $psfile $pdffile
open -a Preview $pdffile

Then, you can add this to your .gvimrc (not .vimrc, as MacVim sources the global gvimrc, which contains the setting of printexpr, after your .vimrc):

set printexpr=system('/path/to/vim_preview\ '.v:fname_in)\ +\ v:shell_error

:hardcopy will work again.

On Thu, 29 Jun 2023 at 14:19, Yongwei Wu <wuyo...@gmail.com> wrote:
>
> Actually it is not a bug of MacVim.
>
> Using techniques described in
>
> https://vi.stackexchange.com/questions/6887/where-does-macvim-send-its-printed-files
>
> I have located the file output by Vim. Opening the file by Preview
> does not succeed. A search confirmed this:
>
> https://www.macrumors.com/2022/10/25/macos-ventura-preview-app-drops-postscript-support/
>
> Anyway, even the result from ps2pdf does not look satisfying to me.
> TOhtml has always been a better solution to me.

[Richard Mitchell]

Advantages of ps2pdf over pstopdf ?

The latter comes with OSX -> /usr/bin/pstopdf

and even got updated on 2023-06-15, so it isn't something leftover/forgotten.

[Lifepillar]

Could MacVim's gvimrc perhaps be updated to include something to this
effect?

fun! MacVimPrintFile(fname)
call system('/usr/bin/pstopdf ' .. fname)
call system('/usr/bin/open -a Preview ' .. fname .. '.pdf')
return v:shell_error
endf

set printexpr=MacVimPrintFile(v:fname_in)

Thanks,
Life.

[Yee Cheng Chin]

Actually this was fixed in MacVim, but I have been busy with different things and traveling and didn't have time to polish up a proper release which is why you are seeing the issue :(

I pushed out a pre-release build (you can access it in the Advanced settings or download from the MacVim release page) but I should really get on to releasing it since it's been like 4-5 months already.

The fix was in https://github.com/macvim-dev/macvim/pull/1390 by using pstopdf since it's bundled with macoS.

--
--
You received this message from the "vim_mac" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_mac+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_mac/u7ko9l%24khj%241%40ciao.gmane.io.

[Richard Mitchell]

Thanks!!

[Lifepillar]

On 2023-06-30, Yee Cheng Chin <ychin....@gmail.com> wrote:
> Actually this was fixed in MacVim

Great! Glad to see that MacVim has embraced Vim 9 script. And I will
borrow your timer trick for my own vimrc.

Thanks,
Life.

[Lifepillar]

On 2023-06-30, Lifepillar <lifep...@lifepillar.me> wrote:
> On 2023-06-30, Yee Cheng Chin <ychin....@gmail.com> wrote:

> The fix was in https://github.com/macvim-dev/macvim/pull/1390

To delete the PDF file synchronously after it has been opened in
Preview, AppleScript can be used:

system($"osascript -e 'tell app \"Preview\" to open POSIX file \"{v:fname_in}.pdf\"'")
delete($"{v:fname_in}.pdf")

osascript should return only after the document has been opened. Running
that will probably ask once for permissions to access files.

Life.

[Yee Cheng Chin]

Yup, there is no reason to not use Vim 9 for bundled scripts since we don't have backwards compatibility to worry about.

Interesting point about using osascript,. I didn't know that. I tested it and it does seem to block. I do want to avoid having to ask about permissions just to print a file (since such permissions could be broad and the user may not want to give it to begin with), and I found that I could trick it into a weird state. In particular, if the pdf file doesn't exist for some reason or is corrupted (I just typed "asdf" into a blank file), you can trick Preview to pop up a dialog box (in the background) saying that it can't open the file but not show the app icon in the Dock, meaning the user has no way of finding it. The precise steps is a little convoluted (you need to close Preview first) and to be fair we shouldn't generate corrupt PDF files, and this actually seems more like a macOS bug per se, but in this case the blocking behavior can actually become a liability. I think I will stick with the timer trick for now but good to know that osascript can block on this for future reference.

--
--
You received this message from the "vim_mac" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_mac+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vim_mac/u7n1ih%2473c%241%40ciao.gmane.io.

[Lifepillar]

On 2023-06-30, Yee Cheng Chin <ychin....@gmail.com> wrote:

> you can trick Preview to pop up a dialog box (in the background) saying

> that it can't open the file but *not *show the app icon in the Dock,

> meaning the user has no way of finding it.

Maybe `activate` can help there?

system($"osascript -e 'tell app \"Preview\"' -e 'activate' -e 'open POSIX file \"{v:fname_in}.pdf\"' -e 'end tell'")

Or maybe with `activate` after open.

> I do want to avoid having to ask about permissions just to print
> a file (since such permissions could be broad and the user may not
> want to give it to begin with)

That's a good point. The timer trick likely makes for a better UX.

Life.

[Yongwei Wu]

I was unaware of the fact that pstopdf came preinstalled, otherwise I
would probably have used it.

This said, I made a quick comparison, and noticed:

- While the resulting files look similar (but not identical), the one
generated by ps2pdf is smaller (33537 vs 206104 bytes in my case).
- Ghost ps2pdf defaults to compatibility with PDF v1.4, while Apple
pstopdf generates a file compatible with PDF v1.3 (not configurable).
- They both use the Courier font, but ps2pdf embeds the PostScript
Type 1 font, while pstopdf embeds the TrueType font. This may be the
main reason for the size difference.

Just some useless info at the weekend. ;-)

On Thu, 29 Jun 2023 at 19:22, Richard Mitchell <rwmit...@gmail.com> wrote:
>
> Advantages of ps2pdf over pstopdf ?

[Yee Cheng Chin]

That's interesting to know about the ps2pdf difference. The default "pstopdf" tool that Apple ships definitely seems like the bare MVP that works just for people who have such needs (which is our case here) without them having to do too much work in supporting. FWIW I actually toyed with the idea of bundling  "ps2pdf" with MacVim (before I found out about the Mac-bundled pstopdf) before I saw the binary size… It's a pretty heavy tool.

--
--
You received this message from the "vim_mac" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_mac+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vim_mac/CADs46ic3nLvd%2Bh8NFfWWNXwBqyqiBg7KKMujC_DaRYRTXZ1tgA%40mail.gmail.com.

[Yee Cheng Chin]

And of course you can configure MacVim / Vim to use whatever tool you want. We are just using pstopdf by default.

[Yongwei Wu]

No objection at all. I said it was just "some useless info at the weekend". ;-)

[Bram Moolenaar]

Thanks for looking into this. Let me know if there is something that I
should include in the generic distribution.

Looking at this, I wonder what we should do when encryption is used.
Writing a copy of the file somewhere, without encryption, is bad then.
Even if we delete it soon after.

I suppose encrypting the file won't be possible, since the reader does
not know how to decrypt it. Or does the Preview app support encryption
somehow?

The alternative is to not use a temp file but write the text through a
pipe/socket. That also avoids the need to find the right moment to
delete the temp file. Can we do this somehow? It may require forking
the process, so that the pipe can be written to asynchronously. Or
using ch_open() or job_start() and one of the callback functions.
Using a buffer instead of a file to store the text.

--
hundred-and-one symptoms of being an internet addict:
263. You have more e-mail addresses than shorts.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Lifepillar]

On 2023-07-03, Bram Moolenaar <Br...@moolenaar.net> wrote:
> I suppose encrypting the file won't be possible, since the reader does
> not know how to decrypt it. Or does the Preview app support encryption
> somehow?

Yes, macOS's Preview supports (at least some?) encrypted PDFs. I did
a quick test by encrypting a random PDF document with qpdf:

qpdf --encrypt PASSWORD OWNERPASSWORD 256 -- in.pdf out.pdf

and by opening out.pdf with Preview, which prompted for a password
before opening the document.

> The alternative is to not use a temp file but write the text through a
> pipe/socket. That also avoids the need to find the right moment to
> delete the temp file. Can we do this somehow?

With Preview? I don't think so. But if one wants to get fancy, the PDF
can be written to the system clipboard and then Preview can be asked to
create a new document from the clipboard's content (using AppleScript).
Then, the clipboard content can be erased.

Or, even better, one could create a (sufficiently large) RAM disk with
something like:

hdiutil attach -nomount ram://204800
diskutil erasevolume APFS TempDisk /dev/diskN

use it as volatile storage, then destroy it:

diskutil eject /Volumes/TempDisk

The RAM disk can likely be formatted with an encrypted file system, too.

Life.

[Bram Moolenaar]

> On 2023-07-03, Bram Moolenaar <Br...@moolenaar.net> wrote:
> > I suppose encrypting the file won't be possible, since the reader does
> > not know how to decrypt it. Or does the Preview app support encryption
> > somehow?
>
> Yes, macOS's Preview supports (at least some?) encrypted PDFs. I did
> a quick test by encrypting a random PDF document with qpdf:
>
> qpdf --encrypt PASSWORD OWNERPASSWORD 256 -- in.pdf out.pdf
>
> and by opening out.pdf with Preview, which prompted for a password
> before opening the document.

I could find help with:
% qpdf --help=encryption
Create encrypted files. Usage:

--encrypt user-password owner-password key-length [options] --

Either or both of user-password and owner-password may be empty
strings. key-length may be 40, 128, or 256. Encryption options are
terminated by "--" by itself.

I don't like passing the password on the command line, but I suppose
there is no other way.

There is no explanation of "user-password" and "owner-password", other
than that they may be empty. Is there a recommended usage?

> > The alternative is to not use a temp file but write the text through a
> > pipe/socket. That also avoids the need to find the right moment to
> > delete the temp file. Can we do this somehow?
>
> With Preview? I don't think so. But if one wants to get fancy, the PDF
> can be written to the system clipboard and then Preview can be asked to
> create a new document from the clipboard's content (using AppleScript).
> Then, the clipboard content can be erased.

The big question is: is this safe? Is it impossible for someone else to
get the text in not encrypted form?

> Or, even better, one could create a (sufficiently large) RAM disk with
> something like:
>
> hdiutil attach -nomount ram://204800
> diskutil erasevolume APFS TempDisk /dev/diskN
>
> use it as volatile storage, then destroy it:
>
> diskutil eject /Volumes/TempDisk
>
> The RAM disk can likely be formatted with an encrypted file system, too.

OK, so there are options. Which one should we use? I can guess that
"ram://" specifies using a RAM disk. What is the "204800" for?

--
If it's sent by ship then it's cargo.
If it's sent by road then it's a shipment.
Dave Allen

[Lifepillar]

On 2023-07-04, Bram Moolenaar <Br...@moolenaar.net> wrote:
>
>> On 2023-07-03, Bram Moolenaar <Br...@moolenaar.net> wrote:
>> > I suppose encrypting the file won't be possible, since the reader does
>> > not know how to decrypt it. Or does the Preview app support encryption
>> > somehow?
>>
>> Yes, macOS's Preview supports (at least some?) encrypted PDFs. I did
>> a quick test by encrypting a random PDF document with qpdf:
>>
>> qpdf --encrypt PASSWORD OWNERPASSWORD 256 -- in.pdf out.pdf
>>
>> and by opening out.pdf with Preview, which prompted for a password
>> before opening the document.
>
> I could find help with:
> % qpdf --help=encryption
> Create encrypted files. Usage:
>
> --encrypt user-password owner-password key-length [options] --
>
> Either or both of user-password and owner-password may be empty
> strings. key-length may be 40, 128, or 256. Encryption options are
> terminated by "--" by itself.
>
> I don't like passing the password on the command line, but I suppose
> there is no other way.

I was using qpdf as a quick way to get an encrypted PDF, as I had it
installed in my system. But there are probably other ways. The passwords
can be read from stdin (one per line) by using @-:

qpdf --encrypt @- @- 256 -- in.pdf encrypted.pdf

> There is no explanation of "user-password" and "owner-password", other
> than that they may be empty. Is there a recommended usage?

Take this with a grain of salt, as I know qpdf only superficially, and
I am not very familiar with PDF encryption either: probably, setting
both user and owner password to the same password suffices:

https://unix.stackexchange.com/questions/535946/encrypting-pdf-with-qpdf-and-only-user-password

>> > The alternative is to not use a temp file but write the text through a
>> > pipe/socket. That also avoids the need to find the right moment to
>> > delete the temp file. Can we do this somehow?
>>
>> With Preview? I don't think so. But if one wants to get fancy, the PDF
>> can be written to the system clipboard and then Preview can be asked to
>> create a new document from the clipboard's content (using AppleScript).
>> Then, the clipboard content can be erased.
>
> The big question is: is this safe? Is it impossible for someone else to
> get the text in not encrypted form?

As the clipboard is a shared memory area, I'd say that no, it is not
safe in general. Although apps such as KeepassXC do paste sensitive
information into the system clipboard for a limited amount of time,
typically ten seconds. If the goal is to defend against other processes
in the same user space, the method below may be safer.

>> Or, even better, one could create a (sufficiently large) RAM disk with
>> something like:
>>
>> hdiutil attach -nomount ram://204800
>> diskutil erasevolume APFS TempDisk /dev/diskN
>>
>> use it as volatile storage, then destroy it:
>>
>> diskutil eject /Volumes/TempDisk
>>
>> The RAM disk can likely be formatted with an encrypted file system, too.

I was able to do that with the following commands; there is probably
a simpler way:

hdiutil attach -nomount ram://20480

This will return the path to the new device, e.g., /dev/disk4.

diskutil erasevolume APFS TempDisk /dev/disk4

This will initialize the disk. Unfortunately, this command does not
return the volume's path, which, for some reason, is /dev/disk5s1 (I
would have expected /dev/disk4s1).

diskutil apfs deleteVolume disk5s1
diskutil apfs addVolume disk5 APFS encrypted -nomount -stdinpassphrase

Enter a password. Finally, mount the encrypted volume:

diskutil apfs unlockVolume disk5s1 -stdinpassphrase

and enter the password.

> OK, so there are options. Which one should we use?

The clipboard and RAM disk options use only commands that are available
in macOS, so they may be preferable to using qpdf, which must be
installed by the user. An encrypted RAM disk may be better than using
the clipboard, although it has some visible side-effects, namely the
disk icon usually appears on the desktop.

But the question is whether it is worth going to such lengths instead of
writing to a temporary file (which is deleted after ten seconds) as
MacVim currently does. Security conscious people have disk encryption
enabled by default at the system level (FileVault), and afaik a deleted
file is not recoverable.

> I can guess that "ram://" specifies using a RAM disk. What is the
> "204800" for?

204800 is the number of 512-byte sectors of the disk. So, the command
above will create a 100MB RAM disk.

Life.

[Bram Moolenaar]

> On 2023-07-04, Bram Moolenaar <Br...@moolenaar.net> wrote:
> >
> >> On 2023-07-03, Bram Moolenaar <Br...@moolenaar.net> wrote:
> >> > I suppose encrypting the file won't be possible, since the reader does
> >> > not know how to decrypt it. Or does the Preview app support encryption
> >> > somehow?
> >>
> >> Yes, macOS's Preview supports (at least some?) encrypted PDFs. I did
> >> a quick test by encrypting a random PDF document with qpdf:
> >>
> >> qpdf --encrypt PASSWORD OWNERPASSWORD 256 -- in.pdf out.pdf
> >>
> >> and by opening out.pdf with Preview, which prompted for a password
> >> before opening the document.
> >
> > I could find help with:
> > % qpdf --help=encryption
> > Create encrypted files. Usage:
> >
> > --encrypt user-password owner-password key-length [options] --
> >
> > Either or both of user-password and owner-password may be empty
> > strings. key-length may be 40, 128, or 256. Encryption options are
> > terminated by "--" by itself.
> >
> > I don't like passing the password on the command line, but I suppose
> > there is no other way.
>
> I was using qpdf as a quick way to get an encrypted PDF, as I had it
> installed in my system. But there are probably other ways. The passwords
> can be read from stdin (one per line) by using @-:
>
> qpdf --encrypt @- @- 256 -- in.pdf encrypted.pdf

That looks useful. We do have to make sure to get the line separator
right and make sure there are no leading or trailing white space characters.

> > There is no explanation of "user-password" and "owner-password", other
> > than that they may be empty. Is there a recommended usage?
>
> Take this with a grain of salt, as I know qpdf only superficially, and
> I am not very familiar with PDF encryption either: probably, setting
> both user and owner password to the same password suffices:
>
> https://unix.stackexchange.com/questions/535946/encrypting-pdf-with-qpdf-and-only-user-password

OK. I found a warning somewhere to not use an empty password, it can be
considered equal to "not encrypted".

> >> > The alternative is to not use a temp file but write the text through a
> >> > pipe/socket. That also avoids the need to find the right moment to
> >> > delete the temp file. Can we do this somehow?
> >>
> >> With Preview? I don't think so. But if one wants to get fancy, the PDF
> >> can be written to the system clipboard and then Preview can be asked to
> >> create a new document from the clipboard's content (using AppleScript).
> >> Then, the clipboard content can be erased.

That still leaves a short time that another program can grab the
password, only a matter of checking the clipboard at the right time.
Hacking tools can be used to slow down the system and have a better
chance of grabbing it. Since Vim is open source we can't use obscurity
to hide the way the password can be accessed. Better not go that way.

> > The big question is: is this safe? Is it impossible for someone else to
> > get the text in not encrypted form?
>
> As the clipboard is a shared memory area, I'd say that no, it is not
> safe in general. Although apps such as KeepassXC do paste sensitive
> information into the system clipboard for a limited amount of time,
> typically ten seconds. If the goal is to defend against other processes
> in the same user space, the method below may be safer.

Right, let's avoid using the clipboard.

> >> Or, even better, one could create a (sufficiently large) RAM disk with
> >> something like:
> >>
> >> hdiutil attach -nomount ram://204800
> >> diskutil erasevolume APFS TempDisk /dev/diskN
> >>
> >> use it as volatile storage, then destroy it:
> >>
> >> diskutil eject /Volumes/TempDisk
> >>
> >> The RAM disk can likely be formatted with an encrypted file system, too.
>
> I was able to do that with the following commands; there is probably
> a simpler way:
>
> hdiutil attach -nomount ram://20480
>
> This will return the path to the new device, e.g., /dev/disk4.
>
> diskutil erasevolume APFS TempDisk /dev/disk4
>
> This will initialize the disk. Unfortunately, this command does not
> return the volume's path, which, for some reason, is /dev/disk5s1 (I
> would have expected /dev/disk4s1).
>
> diskutil apfs deleteVolume disk5s1
> diskutil apfs addVolume disk5 APFS encrypted -nomount -stdinpassphrase
>
> Enter a password. Finally, mount the encrypted volume:
>
> diskutil apfs unlockVolume disk5s1 -stdinpassphrase
>
> and enter the password.

Does this give a prompt, does the user know when to type the password?

> > OK, so there are options. Which one should we use?
>
> The clipboard and RAM disk options use only commands that are available
> in macOS, so they may be preferable to using qpdf, which must be
> installed by the user. An encrypted RAM disk may be better than using
> the clipboard, although it has some visible side-effects, namely the
> disk icon usually appears on the desktop.
>
> But the question is whether it is worth going to such lengths instead of
> writing to a temporary file (which is deleted after ten seconds) as
> MacVim currently does. Security conscious people have disk encryption
> enabled by default at the system level (FileVault), and afaik a deleted
> file is not recoverable.

Every file that was written to a harddisk can be read back.
Relying on "being lucky" is a bad strategy. It used to be OK to
overwrite the file with random data, but with SSDs that doesn't work
(blocks are reallocated when writing the second time, a recovery tool
can still read the older data).

> > I can guess that "ram://" specifies using a RAM disk. What is the
> > "204800" for?
>
> 204800 is the number of 512-byte sectors of the disk. So, the command
> above will create a 100MB RAM disk.

OK, so we divide the file size by 512 and use the resulting number.
Or do we need to round it up to a multiple of 1024? We need to add
something for the directory structure as well.

--
God made the integers; all else is the work of Man.
-- Kronecker

[Lifepillar]

On 2023-07-06, Bram Moolenaar <Br...@moolenaar.net> wrote:
>
>> On 2023-07-04, Bram Moolenaar <Br...@moolenaar.net> wrote:
>> >> Or, even better, one could create a (sufficiently large) RAM disk with
>> >> something like:
>> >>
>> >> hdiutil attach -nomount ram://204800
>> >> diskutil erasevolume APFS TempDisk /dev/diskN
>> >>
>> >> use it as volatile storage, then destroy it:
>> >>
>> >> diskutil eject /Volumes/TempDisk
>> >>
>> >> The RAM disk can likely be formatted with an encrypted file system, too.
>>
>> I was able to do that with the following commands; there is probably
>> a simpler way:
>>
>> hdiutil attach -nomount ram://20480
>>
>> This will return the path to the new device, e.g., /dev/disk4.
>>
>> diskutil erasevolume APFS TempDisk /dev/disk4
>>
>> This will initialize the disk. Unfortunately, this command does not
>> return the volume's path, which, for some reason, is /dev/disk5s1 (I
>> would have expected /dev/disk4s1).
>>
>> diskutil apfs deleteVolume disk5s1
>> diskutil apfs addVolume disk5 APFS encrypted -nomount -stdinpassphrase
>>
>> Enter a password. Finally, mount the encrypted volume:
>>
>> diskutil apfs unlockVolume disk5s1 -stdinpassphrase
>>
>> and enter the password.
>
> Does this give a prompt, does the user know when to type the password?

No prompt: that reads the password from stdin, then decrypts and mounts
the volume. If the password were to be read from a file called pwd.txt,
you would it in the obvious way:

diskutil apfs unlockVolume disk5s1 -stdinpassphrase <pwd.txt

>> > I can guess that "ram://" specifies using a RAM disk. What is the
>> > "204800" for?
>>
>> 204800 is the number of 512-byte sectors of the disk. So, the command
>> above will create a 100MB RAM disk.
>
> OK, so we divide the file size by 512 and use the resulting number.
> Or do we need to round it up to a multiple of 1024?

Rounding is not necessary (but it doesn't hurt), but a minimum size is.
About 20MB seems a safe lower bound.

Note, however, that the commands above will create something that looks
and behaves like a mounted volume, including with a mount point (e.g.,
/Volumes/TempDisk). Even if the file system is encrypted and volatile,
it will still be accessible like a normal volume to anyone with access
to the mount point as long as the disk is mounted (usual file system
permissions will apply to the content).

Is your purpose to include some macOS-specific mechanism for secure
inter-process communication to Vim? Maybe, that should be done using
some OS-specific API.

Life.

[Yee Cheng Chin]

I don't know why your replies got deleted Richard, but regarding your question about encrypted files, Bram is concerned about a very specific use case where Vim can be used to edit files in an encrypted format. See ":h cryptmethod" and ":h :X" for example.

I personally find this to be quite an edge case. People who are paranoid enough to edit encrypted files and need them encrypted at rest are probably unlikely going to be printing their files out, although I could be wrong regarding that depending on what type of content we are talking about here. And "printexpr" has always generated temporary files (v:fname_in) to allow for passing to a print command.

Looking around, it does seem a little hard to directly pass a PDF to Preview to open. In theory it should definitely be possible, and you can copy / paste to clipboard and then load it that way but then you are exposing it to all applications. In macOS there is an ability to take a screenshot and directly send it to Preview.app but I think there is a very specific service (basically a way for Mac applications to advertise what capabilities they have) and Preview.app only exposes it for TIFF image files (which I think is how the screenshot utility sends the image to it without saving to a file).

As for RAM file system, I think they may make it a little more secure, but we still have a core system that the file was exposed to a global name space (file system) that all apps can access.

Otherwise we could just load the Postscript / PDF completely in app instead of going through an external app if we really want to.

On Sat, Jul 8, 2023 at 1:32 AM Richard Mitchell <rwmit...@gmail.com> wrote:

Why was my message/question deleted?

--
--
You received this message from the "vim_mac" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_mac" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_mac+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vim_mac/846f5a73-5d36-4234-98c6-faee4daac21bn%40googlegroups.com.

[Richard Mitchell]

Thanks for the reply!  Your response makes compete sense.

Even my question about my message getting deleted, got deleted.  Odd.