รอให้หน้าต่าง X ปรากฏขึ้น / หายไป (อย่างมีสติ)


11

ภายในเชลล์สคริปต์ฉันต้องรอหน้าต่างที่มีสตริงชื่อปรากฏขึ้นทำการกระทำบางอย่างแล้วรอให้มันหายไปและดำเนินการอื่น ๆ

เมื่อวานนี้ฉันมีรหัสง่ายๆนี้ ปัญหาคือมันไม่สามารถใส่ดิสก์ในสถานะประหยัดพลังงานในขณะที่สคริปต์ยังคงทำงานและอาจใช้เวลาหลายชั่วโมง:

while :; do
    until wmctrl -l | grep -q "$string"; do   # until
        sleep 0.5
    done
    : do action 1

    while wmctrl -l | grep -q "$string"; do   # while
        sleep 0.5
    done
    : do action 2
done

เนื่องจากฉันตัดสินใจว่ารหัสที่กล่าวมานั้นกำลังตื่นขึ้นมาอย่างบ้าคลั่งฉันจึงอ่านเอกสารประกอบของเครื่องมือบรรทัดคำสั่งไม่กี่คำและตัดสินใจที่xdotoolจะรอให้หน้าต่างปรากฏขึ้นและxpropเพื่อพิจารณาเมื่อหน้าต่างหายไป

while :; do
    # we use `until' because sometimes xdotool just crashes
    until xdotool search -sync -all -onlyvisible -pid $pid -name "$string"; do
        :
    done

    # xdotool isn't trustworthy either, so check again
    wmctrl -l | grep -q "$string" ||
        continue

    : do action 1

    xprop -spy -root _NET_CLIENT_LIST_STACKING | while read line; do
        if [[ ! ${_line:-} || $_line = $line ]]; then
            _line=$line
            continue
        else
            _line=$line
            if wmctrl -l | grep -q "$string"; then
                continue
            else
                : do action 2
                break
            fi
        fi
    done
done

ตอนนี้ฉันมีปัญหาใหม่สองประการเกี่ยวกับรหัสด้านบน:

  • xdotoolไม่เพียง แต่ขัดข้องและให้ผลลัพธ์ที่แปลกประหลาดอย่างที่ฉันได้แก้ไขก่อนหน้านี้ แต่มันยังดูดซีพียูประมาณ 15% ในขณะที่รอให้หน้าต่างปรากฏ นั่นหมายความว่าฉันได้กำจัดรหัสง่ายๆที่ทำให้ดิสก์เขียนรหัสที่เหลืออยู่ทำให้สูญเสียซีพียูเป็นเวลาหลายชั่วโมงและความตั้งใจของฉันคือการประหยัดพลังงานตั้งแต่แรก
  • xprop -spyจะแจ้งให้ฉันทราบทุกครั้งที่ฉันเปลี่ยนโฟกัส (ซึ่งฉันได้แก้ไขปัญหา$_lineเสร็จสิ้นแล้ว) หรือสร้างและทำลายหน้าต่าง ที่ทำให้ดิสก์บ่อยกว่า xdotool

ฉันกำลังมองหาโปรแกรมง่ายๆที่รอหน้าต่างพร้อมชื่อ$stringปรากฏหรือหายไป มันอาจเป็นเครื่องมือบรรทัดคำสั่งที่มีอยู่สคริปต์ไพ ธ อนรหัส C ที่คอมไพล์ได้ ... แต่ฉันควรจะรวมมันเข้ากับสคริปต์ของฉัน (แม้ว่าจะเพิ่งเขียนข้อมูลบางอย่างไปยังฟีฟ่า)!


1
จะเป็นการสมเหตุสมผลหรือไม่ที่จะทราบว่าเหตุใดรหัสเก่าของคุณจึงปลุกดิสก์แล้วค้นหาวิธีแก้ปัญหา บางอย่างเช่น chroot และ ramdisk ฉันเดาว่าstrace -f -e trace=file wmctrl -lควรให้ข้อมูล
Hauke ​​Laging

ฉันกำลังใช้fatraceเพื่อตรวจสอบการปลุกดิสก์และมันบอกให้ฉันbashอ่าน/bin/sleepและ/usr/bin/wmctrlทุก ๆ ครึ่งวินาทีนั่นเป็นเหตุผลที่ฉันกำลังมองหาโปรแกรมบางโปรแกรมที่จะรอเหตุการณ์หน้าต่างจริง ๆ ฉันพลาดอะไรไปรึเปล่า?
Teresa e Junior

1
การอ่านสิ่งเหล่านั้นจะไม่ทำให้ดิสก์ตื่นเพราะพวกเขาน่าจะถูกแคชถ้าพวกเขาทำงานสองครั้งทุกวินาที คุณเมานต์ระบบไฟล์ของคุณด้วยเวลากลางคืนหรือไม่? ดูเพิ่มเติมbtraceจากblktraceเพื่อตรวจสอบแหล่งที่มาของกิจกรรมของดิสก์
Stéphane Chazelas

1
หากคุณยังไม่ได้ดูมันxwininfoอาจมีการใช้งานแน่นอนมันจะโหลดไลบรารีที่แชร์น้อยกว่า wmctrl อย่างแน่นอนและทำงานในระดับที่ใกล้กว่ากับ X.
msw

1
@msw ฉันพยายามที่จะแก้ไขไม่ได้ซึ่งเป็นคุณลักษณะการบันทึกอัตโนมัติสำหรับ Google Earth (แหล่งที่มาปิดและข้อบกพร่องในการรายงานคือการเสียเวลา)
Teresa e Junior

คำตอบ:


4

สิ่งนี้จะให้คุณทั้งหมด (OK: ส่วนใหญ่ฉันลืมอะไรบ้าง Sockets?) กิจกรรมของระบบไฟล์ซึ่งรวมถึงการเขียน:

strace -f command 2>&1 | 
  grep -e '^open.*O_CREAT' \
    -e ^write   \
    -e ^mkdir   \
    -e ^rmdir   \
    -e ^unlink  \
    -e ^rename  \
    -e ^chmod   \
    -e ^link    \
    -e ^symlink \
    -e ^mknod

ด้วยข้อมูลนี้สภาพแวดล้อม chroot ที่ใช้งานได้สามารถสร้างขึ้นได้ใน tmpfs (เป็นการกระทำของแหล่งข้อมูลสุดท้ายบางที symlink ไปยัง tmpfs ก็เพียงพอแล้ว) หากโปรแกรมเริ่มทำงานใน RAM chroot โปรแกรมจะไม่สามารถปลุกดิสก์ได้โดยตรง ไม่มีการเขียนลำดับชั้นของระบบไฟล์ลงในดิสก์


ฉันเชื่อว่ามีบางครั้งที่อ่านไฟล์อย่างน้อยเป็นครั้งแรกจะปลุกดิสก์ด้วยใช่ไหม ฉันสงสัยว่าblktraceจะเป็นเครื่องมือที่เหมาะสมสำหรับสิ่งนั้นหรือไม่ แต่จะต้องมีการรวบรวมเคอร์เนล# CONFIG_BLK_DEV_IO_TRACE is not set:( นั่นอยู่นอกเหนือขอบเขตของคำถามนี้ขอบคุณ
Teresa e Junior

1
@TeresaeJunior แน่นอน แต่ใครจะพิจารณาว่าเป็นปัญหา นี่เป็นเรื่องเกี่ยวกับการทำให้สคริปต์ทำงานตลอดเวลาไม่เกี่ยวกับการเริ่มต้นสคริปต์ และคุณสามารถสร้าง tmpfs ได้จากboot.local/ rc.localเพื่อที่คุณจะไม่สามารถเข้าถึงดิสก์ได้แม้ว่าคุณจะเริ่มต้นสคริปต์ในภายหลัง ฉันเพิ่งดูblktrace(ไม่รู้ก่อนหน้านี้) นั่นเป็นที่น่ากลัวดังนั้นผมสงสัยว่าผมจะได้รับการนอนหลับคืนนี้ ...
Hauke Laging

ใช่ฉันไม่ควรกังวลเกี่ยวกับสิ่งนี้อีกต่อไปคุณพูดถูกอีกแล้ว แต่ฉันคิดว่าฉันจะคลายการนอนหลับคืนนี้ด้วยการรวบรวมเคอร์เนลเนื่องจากฉันต้องการตรวจสอบทุกสิ่งที่อาจทำให้ดิสก์ตื่นตลอดเวลาไม่เฉพาะแฮ็ค Google Earth นี้เท่านั้น :)
Teresa e Junior

6

มันอาจจะง่ายกว่าและเชื่อถือได้มากกว่าโดยอาศัยโปรแกรมจัดการหน้าต่างของคุณหรือ X11 เพื่อจัดการสิ่งนี้โดยการเขียนแอปพลิเคชั่น "ของจริง" X11

สิ่งที่คุณต้องการจากเชลล์คือสิ่งที่ลงทะเบียนกับตัวจัดการหน้าต่างและรอประเภทเหตุการณ์ที่ต้องการก่อนที่จะกลับไปที่เชลล์ ... มันเป็นมิตรกับโหลดมากขึ้นถ้าคุณสามารถหลีกเลี่ยงการวนซ้ำภายในเชลล์ ( until xdotool...สาเหตุของคุณโหลดเนื่องจากไม่มีการหน่วงเวลา (สลีป) ภายในลูป)

อ่า ... เห็นได้ชัดว่ามีคุณลักษณะที่เพิ่มมากกว่าปีที่ผ่านมาxdotool --syncไม่มีอยู่ใน distro Linux ปัจจุบันของฉัน (Debian Squeeze) ดังนั้นฉันจึงไม่ได้ลอง

นักพัฒนา xdotool ตอบคำถามที่คล้ายกันกับคุณ: https://groups.google.com/d/msg/xdotool-users/7zfKTtyWm0Q/DM6TSOBUWZMJ


ใช่แน่นอน-syncควรทำในสิ่งที่ฉันต้องการ แต่มันต้องการwhileเพราะในที่สุดมันก็จะพังก่อนที่หน้าต่างจะปรากฎและเสีย CPU มากเกินไป ฉันรวบรวมxdotoolจากแหล่งจริงเพราะอันที่มาจาก Debian นั้นช้าในการพิมพ์อย่างไม่น่าเชื่อ การเขียนแอปพลิเคชันที่โต้ตอบโดยตรงกับ X นั้นเกินกว่าฉันจริง ๆ ขอบคุณ แต่!
Teresa e Junior
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.