ใช้กระบวนการทุบตีพื้นหลังใน Windows 10 โดยไม่ต้องเปิดเทอร์มินัล


13

ผมมักจะใช้ระบบย่อยลินุกซ์เมื่อฉันเขียนโปรแกรมอะไรบน Windows 10 ~เพื่อให้เส้นทางของฉันทั้งหมดเป็นญาติกับ ฉันมีสคริปต์ไพ ธ อนที่ทำงานตลอดไปในพื้นหลังจนกว่าฉันจะฆ่ากระบวนการ ฉันจะทำเช่นนั้นใน Windows 10 bash ที่ไม่มีเทอร์มินัลเปิดได้อย่างไร

สิ่งที่ฉันได้ลอง:

  • bash -c "python3 script.py จาก Run
  • nohup python3 -u script.py จากนั้นปิดเครื่อง
  • setsid python3 script.py จากนั้นปิดเครื่อง

สิ่งเหล่านี้ไม่ได้ผล มีวิธีทำเช่นนี้หรือไม่? อีกวิธีหนึ่งคือมีวิธีการเปลี่ยนเส้นทางเพื่อให้พวกเขาทำงานถ้าฉันเรียกใช้สคริปต์จาก W10 และทุบตีโดยไม่ต้องเปลี่ยนพวกเขาทุกครั้งหรือไม่

คำตอบ:


7

การเพิ่ม WSL ล่าสุดช่วยให้สามารถเริ่มต้นคำสั่ง wsl ได้โดยตรงจากเมนู 'เรียกใช้' หรือเมนูเริ่ม คุณสามารถผนวกเครื่องหมายแอมเปอร์แซนด์เข้ากับคำสั่ง (ลักษณะการทำงานของเชลล์ปกติ) ซึ่งส่งผลให้bashเทอร์มินัลชั่วขณะซึ่งหายไปทันที แต่คำสั่งดำเนินการต่อ

ตัวอย่างภายในเริ่ม»เรียกใช้ :

wsl sleep 20 &
wsl python -c 'import time; time.sleep(20);' &

หากคุณเข้าสู่ 'ตัวจัดการงานของ Windows มันจะแสดงSleepหรือPython2คำสั่งที่ใช้งานเป็นเวลา 20 วินาทีจากนั้นทำการล้างด้วยตนเอง

สิ่งหนึ่งที่ฉันพบคือตัวแปรสภาพแวดล้อมไม่พร้อมใช้งาน ตัวอย่างเช่นDISPLAYหากตั้งค่าในวิธีปกติของ Windows จะไม่ถูกส่งไปยัง WSL สำหรับสิ่งนี้จะต้องมีวิธีที่จะผ่านตัวแปรเหล่านี้ แม้ว่าคำสั่งจะไม่สนับสนุนการตั้งค่าตัวแปรที่ต้องการผ่านอาร์กิวเมนต์บรรทัดคำสั่งคุณสามารถทำได้ด้วยbashตนเอง:

# direct, command-dependent
wsl emacs --display=:0 &

# indirect, more flexible
wsl bash -c "DISPLAY=:0 emacs" &

หมายเหตุ: ฉันกำลังเรียกใช้ win10_64 เวอร์ชัน 1709 (ระบบปฏิบัติการ Build 16299.64)


13

ปรับปรุง

Microsoft ได้แจ้งเรื่องนี้ กระบวนการพื้นหลัง / daemon ได้รับอนุญาตให้ทำงานต่อไปแม้หลังจากbash.exe(หรือกระบวนการตัวเรียกใช้งาน WSL อื่น ๆ ) ถูกปิด ต้องสร้าง Win10 ล่าสุด (ฤดูใบไม้ผลิ 2018 สำหรับการเผยแพร่สาธารณะสร้าง 17046 หรือมากกว่า) เป็นสิ่งจำเป็น

ด้านล่างนี้ถูกเก็บรักษาไว้สำหรับลูกหลาน


เศร้า / ไร้เหตุผลไม่มีทางทำเช่นนี้ Microsoft ในภูมิปัญญาที่ไม่มีที่สิ้นสุดของพวกเขาได้ตัดสินใจว่า WSL (ระบบย่อย Windows สำหรับ Linux) จะทำงานเฉพาะเมื่อคุณbash.exeเปิดกระบวนการ ปิดหน้าต่างสุดท้าย (หรืออาจปิดหน้าต่างสุดท้ายฉันไม่แน่ใจว่ามันจะทนต่อการถูกหัวขาดหรือไม่) และ WSL ปิดตัวลงเพื่อฆ่ากระบวนการทั้งหมด

ข้ออ้างสำหรับเรื่องนี้คือ "เพื่อการอนุรักษ์ทรัพยากร" ซึ่งไร้สาระในหลายระดับ แต่ที่สะดุดตาที่สุดก็เพราะคอมพิวเตอร์ของฉันมีทรัพยากรเหล่านั้นและพวกมันก็พร้อมใช้งาน! หากฉันต้องการให้กระบวนการทำงาน ถ้าฉันไม่ต้องการให้มันวิ่งฉันสามารถฆ่ามันได้ สำหรับบางสิ่งที่ตั้งใจไว้อย่างชัดเจนว่าเป็นเครื่องมือสำหรับนักพัฒนาบางครั้งก็รู้สึกว่า WSL ใช้งานได้เป็นของเล่นเท่านั้นและผู้ใช้ไม่สามารถเชื่อถือได้ว่ารู้ว่าพวกเขากำลังทำอะไรอยู่

ทั้งนี้หากคุณต้องการนี้คงโหวตให้พิจารณาการเปิดใช้งาน cron, ภูตและงานพื้นหลังบนหน้า UserVoice ปัจจุบันนี้เป็นคำขอที่ได้รับการโหวตเป็นอันดับสองและเป็น "ในงานในมือ"


"ที่สะดุดตาที่สุดเพราะคอมพิวเตอร์ของฉันมีทรัพยากรเหล่านั้นและพวกเขาก็พร้อมที่จะใช้" เป็นอย่างดี! จริงๆมัน boggles ใจ ...
airstrike

ฉันได้สร้าง 17134 และไม่สามารถมีงานพื้นหลังโดยไม่มีหน้าต่างทุบตี
John Pick

@JohnPick พวกเขาจะไม่เปิดโดยอัตโนมัติหลังจากรีบูต แต่พวกเขาควรจะยังคงทำงานเมื่อปิดหน้าต่าง (ตราบใดที่พวกเขาไม่ได้ติดกับมันแน่นอน)
CBHacking

@CBHacking เพื่อให้เฉพาะเจาะจงมากขึ้นถ้าฉันเริ่มเซิร์ฟเวอร์ Node.js ในพื้นหลังนั่นเป็นทั้งงาน ( jobs) และกระบวนการ ( ps aux) ฉันสามารถใช้fgเพื่อนำมาไว้ข้างหน้า แต่หลังจากที่ฉันปิดหน้าต่าง bash สุดท้ายและเปิดหน้าต่าง bash ใหม่งานจะหายไปกระบวนการยังทำงานอยู่และฉันไม่สามารถย้ายกระบวนการไปยังส่วนหน้าได้ ขออภัยถ้าคำศัพท์ของฉันปิด
จอห์นเลือก

@ JohnPick Ah นั่นเป็นปัญหาที่แตกต่างอย่างสิ้นเชิง - คำถามนี้เกี่ยวกับกระบวนการไม่ใช่เกี่ยวกับการจัดการงานของเชลล์ - และควรได้รับการถามจากที่อื่น แต่คำตอบนั้นง่ายพอที่ฉันจะให้ที่นี่: เปิดตัวกระบวนการภายใต้tmuxหรือscreenสนับสนุน ติดใหม่กับเทอร์มินัลอื่น เครื่อง Linux (และ * อื่น ๆ ) ที่ใช้งานอยู่จะมีข้อ จำกัด เหมือนกัน
CBHacking

2

ใช่มันเป็นไปไม่ได้ในขณะนี้

แต่เป็นไปได้ที่จะให้มัน "ปรากฏ" เหมือนกระบวนการพื้นหลังที่มีกลอุบายบางอย่าง ฉันต้องการฟังก์ชั่นนี้ค่อนข้างแย่ตัวเองดังนั้นหลังจากผ่านไปสองชั่วโมงฉันก็คิดวิธีแก้ปัญหา

จุดหลักคือการสร้างเชลล์ที่มองไม่เห็นที่คุณเรียกใช้ WSL Bash ไปกับ VBScript จากนั้นคุณสามารถเรียกใช้สคริปต์นั้นเมื่อเริ่มต้น การจัดตารางงานที่เหมาะสมไม่ทำงานด้วยเหตุผลแปลก ๆ

ด้าน Linux เพื่อเปิดใช้งาน daemons คุณสามารถมีระบบสตาร์ทอัพพื้นฐานของคุณเองซึ่งละเมิด. bashrc เป็นต้น

กระบวนการนี้รายละเอียดที่นี่ในเอกสารฉบับนี้ผมเขียนhttps://emil.fi/bashwin ฉันไม่ได้ใช้การตรวจสอบงาน แต่ควรขยายได้ง่าย


2

คุณลองวิธีนี้แล้วหรือยัง

มันใช้ผู้ช่วย WSH เพื่อเปิดแอปพลิเคชันใด ๆ ที่ซ่อนอยู่

จากนั้นคุณสามารถสร้างงานใหม่ใน Tak Scheduler เพื่อเรียกใช้คำสั่งเมื่อคุณเข้าสู่ระบบ สิ่งที่ต้องการwscript <path to runHidden.vbs> bash.exe -c "python script.py"


2

มันพาฉันไปตลอดกาล แต่ฉันพบวิธีที่ซับซ้อนอย่างยิ่งยวดในการทำ (จากไฟล์แบตช์):

start bash -c "DISPLAY=:0 [command] & (sleep 0.5 && kill -n 9 $$)"

นี่คือรายละเอียดของสิ่งที่มันทำและทำไม:

  • `start ': เพื่อทำให้หน้าต่างไฟล์แบตช์หายไป
  • `bash -c`: ให้คุณเรียกใช้คำสั่ง bash
  • `DISPLAY =: 0`: ตั้งค่า X-server ของคุณ
  • `[command]`: คำสั่ง / คำสั่งของคุณ (`[คำสั่ง && [คำสั่ง]]
  • `&`: เพื่อให้คำสั่งถัดไปทำงานหลังจากที่มันเริ่มต้นและไม่เมื่อมันเสร็จแล้ว
  • `sleep 0.5`: เพื่อให้แน่ใจว่ากระบวนการได้เริ่มขึ้นแล้ว
  • `&&`: เพื่อให้คำสั่งถัดไปทำงานหลังจากที่ทำเสร็จและไม่ใช่เมื่อเริ่มต้น
  • `kill -n 9 $$`: เพื่อฆ่า bash shell ดังนั้นมันจึงเป็นเพียงแอปพลิเคชั่นกราฟิก

หมายเหตุ: DISPLAY=:0ชุดไปยังเซิร์ฟเวอร์ X :0ที่ หากต้องการเปลี่ยนเป็น (เช่น) :1ให้ทำDISPLAY=:1ฯลฯ

หมายเหตุ: startจำเป็นเฉพาะเมื่อมาจากสคริปต์ชุดงาน หากมาจากเทอร์มินัลคุณไม่ต้องการสิ่งนี้

หมายเหตุ: sleepจำเป็นต้องตั้งค่าต่างกันสำหรับแต่ละแอปพลิเคชัน คุณอาจต้องละเว้นมัน


0

ฉันไม่รู้ว่า Windows Service Manager (SrvMan) จาก http://tools.sysprogs.org/srvman/จะทำงานให้คุณได้ดีแค่ไหน แต่มันก็ใช้ได้กับฉันสำหรับโปรแกรมอื่น ๆ ในความเป็นจริงฉันได้ลองใช้ "bash.exe" เป็นบริการเพื่อดูว่ามันจะทำงานได้หรือไม่และฉันคิดว่าฉันต้องใช้คนจรจัดอีกเล็กน้อยเพื่อให้ LAMP ทำงานในพื้นหลังจริง ๆ


1
ที่อยู่นี้คำถามของวิธีการเรียกใช้สคริปต์ Python ในพื้นหลังได้อย่างไร
สกอตต์
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.