blob: 0beeabf8ad76fcc309e4245bdae710872be6ab76 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
|
# a pardes launched INSIDE a pardes hands its argument to the outer one.
#
# No harness support is needed to get a genuinely nested launch: a pane
# shell's parent IS the app under test, so `$(readlink /proc/$PPID/exe)` in a
# pane is this exact binary, and running it from there makes a real
# descendant — the same process tree a person typing `pardes foo.txt` in a
# pane produces. Each arm gets its own `start` so the Look never has to be
# aimed at a pane a previous arm moved.
#
# What discriminates is the GOLDEN GRID, not the `wait` below it: a nested
# pardes that opened its own UI in the pane would show the same file, so the
# content wait passes either way. The layout is what differs — an outer file
# pane beside the shell versus a whole second topbar inside it — and the
# `cursor=` on the first arm's header moves the moment that changes.
#
# Long waits on purpose: this forks and execs a whole second pardes.
dirmk nestdir
file nestdir/inside-nested.txt marker
file nested.txt hello-from-nested\nsecond-nested-line\n
# --- a FILE argument: a file pane appears in the OUTER instance ---
start 30 100
wait 8000 $
stable 700 20000
text $(readlink /proc/$PPID/exe) nested.txt
key enter
# the CONTENT, not the border: the shell only ever echoed the file's NAME
# (see above for why the grid, not this line, is the real assertion)
wait 15000 hello-from-nested
stable 700 20000
snap file-arg
# --- no argument: the spicy message, in the pane, and no second UI ---
start 30 100
wait 8000 $
stable 700 20000
text $(readlink /proc/$PPID/exe)
key enter
wait 15000 already inside pardes
stable 700 20000
snap no-arg
# --- a DIRECTORY argument: a shell there, greeted with ls ---
start 30 100
wait 8000 $
stable 700 20000
text $(readlink /proc/$PPID/exe) nestdir
key enter
wait 15000 inside-nested.txt
stable 700 20000
snap dir-arg
|
