<tmpm697>
but i can't wrap foot as i need to know its `pid` when i start foot
<tmpm697>
but i also need title reflect current `empty command` when i start foot
<tmpm697>
like just show the title like `$pwd` when start foot
<tmpm697>
i.e: when current zsh pwd when start foot is /path/folder, the title will be `/path/folder` when foot first started
<tmpm697>
i start foot like: `foot -T <my_titile> --config <my_config>` --> i have to set a fix title at first to manage the foot window
<tmpm697>
but i want the title reflect current shell's path when 1st started, how to?
<tmpm697>
but even if i'm not settings `-T <title>` --> foot will always fall back to its default `terminal` in foot.ini file
<tmpm697>
my foot window title only change if i enter the 1st command
<tmpm697>
`tmux` provide somthing like `set -g set-titles-string <pattern_here>` --> this will instruct its window title to change according to --> prefer if foot support this.
<tmpm697>
so if i 1st start `tmux` the window title is there correctly.
<bookworm>
why wouldn't you be able to use a wrapper script?
<bookworm>
you can just exec into foot after all
<tmpm697>
i need to know foot's pid when i start foot, can't do that with wrapper?
cbb has joined #foot
<bookworm>
it's still the same process
<bookworm>
exec replaces the currently running shell
<tmpm697>
what u mean by this? `"you can just exec into foot after all"`
<tmpm697>
you mean foot pid will be the same as wrapper pid?
<bookworm>
yes
<ninewise>
if the wrapper script ends with `exec foot ...`, yes
<cbb>
foot's PID isn't the same as the child PID
<bookworm>
like inside of the script you use exec, a shell built in
<bookworm>
cbb: what child?
<cbb>
bookworm: there's always a child process
<bookworm>
no?
<cbb>
in this case probably a shell
<bookworm>
I think you are missing the context
<tmpm697>
correct me if i'm wrong, so if i have `vi script.sh: start_foot_terminal.sh &; pid=$(echo $!)` --> this is the same as `vi script.sh: foot -T title --config /my/config &; pid=$(echo $!)` ?
<bookworm>
they wanna set the win title. For that a wrapper script as linked above can be used. They need the pid of foot after the spawn. Theit worry is that pid of foot is not pid of wrapper, but that's not the case there
<tmpm697>
in sway/config i will have: `exec script.sh`
<ninewise>
tmpm697, yes, but only if `start_foot_terminal.sh` ends in `exec foot -T title --config /my/config`
<ninewise>
as a side note, use `pid="$!"` instead of `pid=$(echo $!)`
<bookworm>
with the added constraint that you can't do anything with that pid them from the wrapper
<bookworm>
then*
<bookworm>
unless you pass that thing back, your wrapper ceases to exist and takes that local var with it to the grave
<tmpm697>
what u mean by "cant' do anything with that pid"?
<bookworm>
so, what are you doing with the pid?
<tmpm697>
from that pid I will set `mark` in sway
<bookworm>
how?
<tmpm697>
like `swaymsg '[pid=$pid] mark my_mar`
<bookworm>
yes. But how do you pass the pid to sway?
<tmpm697>
`mark` that foot window in sway
<tmpm697>
check above command, sway support pid of a process that has window to set a mark on it.
<bookworm>
yes. I'm asking where you call that (and when)
<tmpm697>
i call set mark in `script.sh` right after get the pid
<cbb>
bookworm: oh yeah, my bad... I missed the context from that wiki page
<bookworm>
then why are you arguing that you can't use a wrapper?
<bookworm>
you don't need to keep the pid the same as your wrapper
<bookworm>
your wrapper can simply spawn foot, get the pid, call swaymessage and die
<tmpm697>
i just need to know if pid is the same with exec and that wrapper
<tmpm697>
ok ty
<bookworm>
note that you do not want exec in your case
<bookworm>
anything you try to exec below it is dead code that never gets executed, but you'll figure that out quickly enough ;)
<tmpm697>
so if in wrapper i'm not use `exec foot` --> pid of wrapper will still the same as foot process?
<bookworm>
no it won't but you don't need it
<tmpm697>
what u mean i `don't need it`?
<tmpm697>
i need to run other command after `start_foot_terminal.sh` wrapper
<bookworm>
you don't need two indirections. You'll use the argument parsing from the example wrapper and then normally spawn foot in a subcommand. You then immediately *from the same wrapper* issue the swaymsg command
<bookworm>
the wrapper returns to sway and off it goes through the other config directives
<tmpm697>
i don't want to bunddle wrapper with `sway command`