On 2023/02/17 14:51, Marcus MERIGHI wrote:
> Hello,
>
> s...@spacehopper.org (Stuart Henderson), 2023.02.17 (Fri) 10:50 (CET):
> > On 2023/02/17 08:13, Stefan Hagen wrote:
> > > Marcus MERIGHI wrote (2023-02-11 17:14 CET):
> > > > sh+openbsd-po...@codevoid.de (Stefan Hagen), 2023.02.10 (Fri) 19:28
> > > > (CET):
> > > > > here is a command line signal client. It's lacking a lot of features,
> > > > > but basic text send/receive functionality is there.
> > > >
> > > > for me the client quits upon receiving messages, reliably.
> > > >
> > > > 2023-02-11T15:50:33.433155Z ERROR panic: thread 'main' panicked at
> > > > 'called `Result::unwrap()` on an `Err` value: Error { kind:
> > > > Uncategorized, message: "no current exe available (short)" }':
> > > > /usr/ports/pobj/gurk-rs-0.3.0/gurk-rs-0.3.0/modcargo-crates/ \
> > > > notify-rust-4.5.10/src/notification.rs:23
> > >
> > > Oh, that's unfortunate and it's keeping me from going forward. I know it
> > > works for me and kn@ had some success. But I also don't want to import
> > > something that only works for half of the people. Missing features are
> > > fine, but it shouldn't break like that.
> >
> > Does it work if you use the full path when running the binary?
>
> Yes, it does! Tried multiple times.
>
> I receive messages and the chats that I've been part of since linking to
> the phone have popped up, nice.
So this is one of those programs which wants to know which path you used
to run it, which is a standard library feature provided in some of the
newer languages and is available in some OS (it's not possible to
guarantee that the file reachable at that path is still the same, or
even exists at all, but for the purppses of what the software wants
that's good enough).
Here it wants to yse it to set the application name and icon in desktop
notifications.
OpenBSD doesn't have a way to do this at all unless it can retrieve
the full path from argv (sshd needs similar for reloading).
As far as software in ports goes, it probably makes sense to patch to
use the location where the package installs the binary - in this case
it's in "notify-rust", so it would probably make sense to patch
that (look for "current_exe" to use a hardcoded path string instead.
> > > > Regarding
> > > > Signal Messenger client for the terminal written in Rust.
> > > >
> > > > While beeing completely right it does not tell that it is a Text User
> > > > Interface (TUI). Maybe steeli^Wtaking a bit from tut(1)'s description?
> > > >
> > > > So
> > > > TUI for Mastodon with vim inspired keys
> > > > becomes
> > > > Signal Messenger client TUI with strange key bindings
> > >
> > > Ironically, I find "for the terminal" clearer than TUI.
> >
> > me too.
>
> To me there's two types of user interfaces "for the terminal".
>
> Command line, based on stdin/stdout/stderr, like wc(1).
>
> Or an program that is started from the command line but its user
> interface is not based on stdin/stdout/stderr, like mutt.
>
> "for the terminal" does not tell which one of these it is.
>
> Am I getting it wrong? In what way?
We used to just say things like "curses UI" and everyone knew what it
meant, but since it doesn't actually use curses that seems wrong...
Personally I'd expect to see "command-line" if it's a command line
application and for most other wording that is obviously related to the
console rather than X or a daemon I'd expect some kind of (probably
full-screen) terminal ui.
Not that it matters all that much.
