Starship: พรอมป์ต์ขนาดเล็ก รวดเร็ว และปรับแต่งได้สำหรับทุกเชลล์

 (starship.rs)
8 คะแนน โดย GN⁺ 2025-06-25 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • Starship เป็นโปรเจกต์โอเพนซอร์สสำหรับพรอมป์ต์ที่มี น้ำหนักเบา ประสิทธิภาพสูง และยืดหยุ่น ซึ่งใช้งานได้ในสภาพแวดล้อมเชลล์ที่หลากหลาย
  • รองรับ เชลล์หลักเกือบทั้งหมด เช่น Bash, Zsh, Fish, Powershell, Tcsh จึงมีความเข้ากันได้อย่างกว้างขวาง
  • สามารถตั้งค่าและใช้งานได้ด้วยการ เพิ่มสคริปต์เริ่มต้น ของแต่ละเชลล์แบบง่าย ๆ
  • เขียนด้วย Rust จึงให้ทั้งความเร็วและความปลอดภัย พร้อมแจกจ่ายในรูปแบบไบนารีเดียว
  • ปรับแต่งได้แม้กระทั่งรายละเอียดเล็กน้อยทุกส่วน
  • รองรับการจัดสภาพแวดล้อมแบบเดียวกันบนหลายแพลตฟอร์ม เช่น Android, BSD, Linux, macOS, Windows ช่วยเพิ่มประสิทธิภาพการทำงานและความสะดวกในการใช้งาน

โปรเจกต์โอเพนซอร์ส Starship

  • Starship เป็นเครื่องมือพรอมป์ต์ที่รองรับทั้งประสิทธิภาพและการปรับแต่งไปพร้อมกัน และใช้งานได้บนระบบปฏิบัติการและเชลล์ที่หลากหลาย
  • เมื่อเทียบกับพรอมป์ต์แบบเดิมที่ค่อนข้างหนัก จุดเด่นคือ การตอบสนองที่รวดเร็ว และ ใช้ทรัพยากรต่ำ อีกทั้งยังปรับแต่งได้สูง จึงช่วยเพิ่มผลิตภาพในการพัฒนา

วิธีตั้งค่าในแต่ละสภาพแวดล้อมเชลล์

  • Bash:
    • เพิ่มโค้ด eval "$(starship init bash)" ไว้ท้ายไฟล์ ~/.bashrc
  • Fish:
    • เพิ่ม starship init fish | source ไว้ท้ายไฟล์ ~/.config/fish/config.fish
  • Zsh:
    • เพิ่มโค้ด eval "$(starship init zsh)" ไว้ท้ายไฟล์ ~/.zshrc
  • Powershell:
    • เพิ่ม Invoke-Expression (&starship init powershell) ลงในไฟล์ Microsoft.PowerShell_profile.ps1
    • สามารถตรวจสอบตำแหน่งไฟล์โปรไฟล์ PowerShell ได้จากตัวแปร $PROFILE
  • Ion:
    • ใส่โค้ด eval $(starship init ion) ลงในไฟล์ ~/.config/ion/initrc
  • Elvish:
    • รองรับเฉพาะเวอร์ชัน v0.18 ขึ้นไป
    • เพิ่มโค้ด eval (starship init elvish) ลงในไฟล์ ~/.elvish/rc.elv
  • Tcsh:
    • ใส่โค้ด eval \starship init tcsh`` ลงในไฟล์ ~/.tcshrc
  • Nushell:
    • รองรับเฉพาะ v0.96 ขึ้นไป และมีความเป็นไปได้ว่าวิธีการตั้งค่าอาจเปลี่ยนในอนาคต
    • ตรวจสอบพาธไฟล์ตั้งค่าได้ด้วยคำสั่ง $nu.config-path
    • ใช้โค้ด starship init nu | save -f ... กับพาธดังกล่าวเพื่อเปิดใช้งาน
  • Xonsh:
    • ใส่โค้ด execx($(starship init xonsh)) ไว้ท้ายไฟล์ ~/.xonshrc
  • Cmd (ต้องใช้ Clink):
    • ต้องใช้ Clink v1.2.30 ขึ้นไป
    • สร้างไฟล์ starship.lua แล้วบันทึกไว้ในไดเรกทอรีสคริปต์ของ Clink
    • ภายในเพิ่มโค้ด load(io.popen('starship init cmd'):read("*a"))()

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
tujuc 2025-06-25

พอเห็นสิ่งที่ใช้อยู่มาหลายปีถูกโพสต์ขึ้นมาก็รู้สึกแปลกใหม่ดีครับ :)
ผมใช้มาตั้งแต่ตอนที่มันถูกปล่อยออกมาเป็นธีม Zsh แล้วล่ะ... ฮ่าๆๆๆๆ
 
GN⁺ 2025-06-25
ความเห็นจาก Hacker News

  • ฉันเป็นผู้ใช้ที่ชอบพรอมป์ต์แบบจัดเต็ม และมักใช้ Shell Bling Ubuntu ผ่าน Starship เวลาตั้งค่าเครื่องสำหรับพัฒนา
    แต่สไตล์แบบนี้ก็ไม่ได้เหมาะกับทุกคน
    ถ้าอยากเพิ่มเฉพาะข้อมูลที่หนาแน่นและมีประโยชน์ที่สุด แนะนำให้แสดงแค่เวลาที่พรอมป์ต์ปรากฏและระยะเวลาที่คำสั่งล่าสุดใช้รัน
    แค่มีข้อมูลสองอย่างนี้ก็ทำให้เข้าใจได้ง่ายว่าอะไรเกิดขึ้นเมื่อไร และมีประโยชน์มากต่อการดีบักหรือการเก็บบันทึกในภายหลัง
    วิธีนี้เป็นเคล็ดลับที่ได้มาจากหนังสือ Networking for System Administrators ของ Michael W. Lucas และฉันก็มักแนะนำหนังสือเล่มนี้ให้กับนักพัฒนาที่อยากเรียนพื้นฐานด้านเครือข่าย
    ถ้าอยากได้ nerd point เพิ่มอีกหน่อย ก็ให้แสดงเวลาเป็นวินาทีตาม UNIX epoch
    ข้อดีคือคำนวณ time delta ได้ง่ายมาก
    ดูได้ที่ Shell Bling Ubuntu repo

    • ใน nushell ข้อมูลพวกนี้มีมาให้โดยปริยายอยู่แล้ว
      ในประวัติการรัน (history) สามารถดูรายละเอียดอย่าง timestamp ตอนเริ่มคำสั่ง, เวลาที่ใช้รัน, ไดเรกทอรีปัจจุบัน, สถานะการจบการทำงาน ฯลฯ ได้
      มันสะดวกมากเพราะไม่เพียงแค่บอกช่วงเวลาระหว่างการรันคำสั่ง แต่ยังแสดงเวลาที่คำสั่งนั้นใช้ทำงานจริงโดยตรงด้วย

    • แทบไม่เคยคัสตอมพรอมป์ต์เลย
      เพราะถ้าใช้ emacs ก็เห็นข้อมูลที่ต้องการทั้งหมดใน editor อยู่แล้ว
      จะตั้งค่า Starship ก็เฉพาะเวลาที่ต้องให้คนอื่นดู เช่น ตอน pair programming และจะเปิดแอป terminal แยกต่างหากไว้ จะได้ไม่ต้องโชว์การตั้งค่าของตัวเอง

    • exit code (รหัสจบการทำงาน) ของคำสั่งก่อนหน้าก็เป็นข้อมูลที่มีประโยชน์มาก ด้วยเหตุผลคล้ายกันกับข้างบน

    • การแสดงเวลาปัจจุบันในรูปแบบที่คนอ่านง่ายก็ช่วยได้พอสมควร
      และถ้าคำสั่งก่อนหน้าจบด้วยสถานะที่ไม่ใช่ 0 (คือทำงานล้มเหลว) การแสดงมันออกมาก็ช่วยเรื่องการดีบักได้

    • สำหรับฉัน มีแค่ข้อมูลไดเรกทอรีปัจจุบันก็พอแล้ว
      แค่เปลี่ยนสีพรอมป์ต์ตามสถานะสำเร็จ/ล้มเหลวของคำสั่งล่าสุดก็พอ
      ข้อมูลเพิ่มเติมค่อยไปดูแยกต่างหากเมื่อจำเป็น

  • แอบสงสัยว่าโครงสร้างอายุของผู้ใช้ Starship เป็นอย่างไร
    สำหรับตัวฉันเอง พอเวลาผ่านไปก็สนใจการคัสตอมพรอมป์ต์น้อยลงมาก
    สุดท้ายแล้วไม่ว่าจะแต่งพรอมป์ต์ให้ละเอียดแค่ไหน ข้อมูล 90% ที่แสดงก็ไม่จำเป็นใน 90% ของเวลา
    ยิ่งมีข้อมูลมากเกินไปก็ยิ่งกลายเป็น visual noise จนสมองมองข้าม และสุดท้ายก็ลืมไปด้วยซ้ำว่ามันมีข้อมูลนั้นอยู่
    ข้อมูลที่สำคัญจริง ๆ ก็มีข้อจำกัดถ้าจะยัดไว้ในพรอมป์ต์ เช่น แค่บอกว่ามี Git branch เปลี่ยนไป ก็ไม่ได้ทำให้รู้ว่าไฟล์ไหนถูกแก้ สุดท้ายก็ต้องรันคำสั่งเพิ่มอยู่ดี

    • มีประสบการณ์ทำงานพัฒนามากกว่า 20 ปี
      และมองว่าการมีข้อมูล Git ในพรอมป์ต์มีประโยชน์มาก
      ถึงจะไม่ได้บอกข้อมูลละเอียดทุกอย่าง แต่ก็ช่วยเตือนว่ามีการเปลี่ยนแปลงที่ยังไม่ได้ commit หรือมี stash ที่ลืมไว้
      Starship ดูน่าสนใจเลยติดตั้งทันที แต่ส่วนอย่างการแสดงเวอร์ชันของเครื่องมือกลับรู้สึกว่ารกเกินไป สุดท้ายเลยถอนออก
      ตัวเลือกอย่างเวลาการรันคำสั่งหรือสถานะสำเร็จ/ล้มเหลวก็ถือว่าดี แต่สิ่งที่ได้กลับมาไม่คุ้มกับความพยายามในการดูแล config ที่ซับซ้อน

    • ในมุมของคนทำงานสายนี้มากว่า 25 ปี ฉันมักไม่ค่อยใช้เครื่องมือล้ำ ๆ หวือหวาสมัยใหม่
      เมื่อก่อนจะใช้ PS1 ที่เรียบง่ายมากอย่าง <pre><code>export PS1="[\033[1;32m][\t \u@\h \w]\$[\033[0m]"</code></pre> ซึ่งแสดงแค่เวลา บัญชีผู้ใช้ โฮสต์ที่เชื่อมต่อ และพาธปัจจุบัน
      เคยลองพรอมป์ต์ขั้นสูงแบบอื่นมาหลายครั้ง แต่แทบไม่ช่วยอะไร
      ตอนนี้กลับใช้ Starship มาได้ดีหลายปีแล้ว
      คัสตอมให้แสดงเฉพาะข้อมูลที่จำเป็นน้อยที่สุด จึงใช้งานได้เร็วและสบายมาก

    • ส่วนที่มีประโยชน์ที่สุดอย่างหนึ่งในพรอมป์ต์ที่ฉันคัสตอมคือการแสดง exit status (รหัสจบการทำงาน) ของคำสั่งก่อนหน้า
      บางครั้งคำสั่งล้มเหลวโดยไม่มีข้อความ error ออกมาเลย ดังนั้นการมีตัวบอกความล้มเหลวจึงเป็นสัญญาณสำคัญมาก
      แต่เพื่อไม่ให้กลายเป็น noise ในเวลาปกติ ฉันจะแสดงเฉพาะตอนที่ล้มเหลวเท่านั้น
      ตัวอย่าง: <pre><code>» true » false (last command returned 1.)</code></pre>
      ถ้าจบเพราะ signal ก็แปลออกมาแสดงด้วย เช่น "last command exited on SIGSEGV"
      และในทางกลับกัน มันก็ยังมีประโยชน์ในกรณีที่โปรแกรมพิมพ์ข้อความ error ออกมา แต่กลับจบด้วย success code

    • ในฐานะผู้ใช้ระดับ "very senior" ที่ใช้ UNIX มาหลายสิบปี ฉันชอบ Starship minimal mode เพราะดูสะอาด
      เมื่อก่อนเสียเวลาหลายปีกับการตั้งค่า zsh หลายแบบ แต่ตอนนี้แทบไม่มี hassle แล้ว
      ถ้าคุณเดาว่าผู้ใช้ Starship คงเป็นคนรุ่นใหม่สาย JavaScript ที่ใส่ emoji รัว ๆ ก็ขอบอกว่ามีคนแบบฉันใช้ด้วยเหมือนกัน

    • ถ้ามองกว้างขึ้น นี่เป็นปรากฏการณ์ที่เกิดกับสภาพแวดล้อมคอมพิวเตอร์โดยรวม
      ตอนเด็ก ๆ เคยหมกมุ่นกับการสร้าง OS เองด้วย Gentoo, ตั้งค่า CPU optimization flags, window manager, alias และฟังก์ชันใน bashrc รวมถึงพรอมป์ต์
      งานปรับแต่งแบบนี้จริง ๆ ก็เป็นประสบการณ์ที่ช่วยให้เติบโตมากทีเดียว
      ถ้าเปรียบกับงานไม้ ช่วงเริ่มต้นเรามักใช้เวลาส่วนใหญ่ไปกับการทำหรือแต่งเครื่องมือกับลูกเล่นเล็ก ๆ แต่พอถึงจุดหนึ่งก็จะเปลี่ยนไปโฟกัสงานจริงเป็นหลัก
      ตอนนี้ก็ยังชอบ Linux อยู่ แต่ในชีวิตที่ยุ่ง ฉันให้ความสำคัญกับ “งาน” มากกว่าการไล่หาประสิทธิภาพหรือความเนี้ยบสมบูรณ์แบบ เลยใช้ Debian กับ KDE แบบค่าปริยายไปเลย

  • ฉันไม่ชอบของตกแต่งที่ไม่จำเป็นหรือข้อมูลล้น ๆ เลยชอบสภาพแวดล้อม terminal แบบมินิมอล
    แต่ Starship แสดงบริบทที่จำเป็นได้ดีตามสถานการณ์ และคัสตอมละเอียดได้มาก
    พรอมป์ต์ปริยายของฉันแสดงแค่ไดเรกทอรีปัจจุบัน เวลา และเครื่องหมาย % ตัวเดียว
    ถ้ามีการตั้ง environment variable บางตัวไว้ (เช่น KUBECONFIG, OS_CLOUD) ก็จะใส่ข้อมูลที่เกี่ยวข้องเข้ามาอย่างเหมาะสม
    เวอร์ชันภาษาอย่าง Go, Python ฯลฯ ก็จะแสดงอัตโนมัติตามบริบทการใช้งาน
    Starship ทำให้การตั้งค่าแบบนี้ทำได้ง่ายมากจริง ๆ และทำงานได้ตรง ๆ โดยมี overhead น้อยมากโดยไม่ต้องพึ่งชุดปลั๊กอิน zsh ที่ซับซ้อน
    โดยเฉพาะเมื่อใช้ร่วมกับ evalcache ความเร็วตอนเริ่มต้นก็ยิ่งดีมาก

  • ในฐานะแฟนของ Starship ขอคอมเมนต์สักเล็กน้อย
    การที่มันพัฒนาด้วย Rust ทำให้ปลอดภัยและเร็ว และเพราะเป็น binary ที่ build เสร็จแล้ว ประสิทธิภาพจึงดีกว่า powerline ที่อยู่บน Python, ohmybash ที่เป็น shell script, ohmyzsh ที่อยู่บน zshell และ spaceship มาก
    รองรับ zsh, bash, sh, fish เป็นเรื่องปกติอยู่แล้ว และยังรองรับ MS Windows CMD กับ Powershell ด้วย
    การมี config ไฟล์เดียวสำหรับจัดการพรอมป์ต์ของทุกระบบนั้นแทบจะหาไม่ได้จากที่อื่น
    ถ้าข้อมูลเยอะเกินไปก็เปลี่ยนให้เรียบง่ายได้ทันที และยังปิดไอคอนได้ด้วย
    มีโมดูลประมาณ 100 ตัว จึงแทบไม่มีขีดจำกัดด้านการคัสตอม

  • ฉันไม่เข้าใจว่าทำไมถึงทำการตลาด Starship ว่า “minimal”
    ในความเป็นจริงมันมีฟีเจอร์สารพัดมากมาย และเวลาที่เห็นคนใช้จริงก็มักเป็นพรอมป์ต์ขนาดใหญ่ที่ติดของตกแต่งเต็มไปหมด
    ฉันใช้แบบเรียบง่ายมากดังนี้

    <pre><code>: ▶</code></pre>

    ถ้าต้องการความมินิมอลจริง ๆ ก็ไม่จำเป็นต้องใช้เฟรมเวิร์กสำหรับคัสตอมแบบนี้เลย

    • เมื่อเทียบกับ shell และพรอมป์ต์อื่น ๆ จุดเด่นของ Starship คือไฟล์ config ยังถือว่าค่อนข้างตรงไปตรงมา แม้ความซับซ้อนจะเพิ่มขึ้นก็ตาม

    • สามารถปิดทุกฟีเจอร์ได้ทั้งหมด
      ตอนนี้ฉันใช้ config มินิมอลประมาณนี้

      <pre><code>format = """ $username\ $hostname\ $shlvl\ $directory\ $git_branch\ $git_commit\ $git_state\ $git_metrics\ $git_status\ $package\ $python\ $rust\ $env_var\ $custom\ $cmd_duration\ $jobs\ $time\ $status\ $shell\ $character"""</code></pre>

    • สุดท้ายแล้ว Starship ก็สามารถใช้แบบมินิมอลได้จริง แต่โดยแก่นแท้มันคือพรอมป์ต์สายแม็กซิมัลลิสต์ที่ใส่ข้อมูลและเนื้อหาได้มากที่สุดเท่าที่จะทำได้
      ถ้ายอมรับจุดนี้ก็น่าจะดี

    • ฉันใช้ลูกศรที่บางกว่านี้อีก

      <pre><code>PROMPT='%{%F{red}%}%~ %{%F{yellow}%}% › %{%F{reset_color}%}%'</code></pre>

      สะอาด เรียบง่าย และมินิมอล

  • แปลกใจที่มีหลายคนสับสนระหว่าง “คัสตอมได้” กับ “แม็กซิมัลลิสม์”
    ค่าปริยายอาจจะเยอะไปหน่อย แต่ก็ลดทอนได้เท่าที่ต้องการ
    ฉันทำงานกับหลาย AWS environment และหลาย runtime ดังนั้นข้อมูลบริบทในพรอมป์ต์จึงช่วยได้มากจริง ๆ
    ส่วนตัวใช้คู่ Starship + Nushell มานานมากตลอด

  • ชอบตรงที่ติดตั้งครั้งเดียวแล้วแทบไม่ต้องยุ่งกับมันอีก
    ฉันอยากเห็นทันทีว่า shell ตอนนี้เป็น node 20 หรือ 22, rust เป็น stable หรือ nightly
    มันแสดงสิ่งเหล่านี้ให้ได้เลยโดยไม่ต้องทำอะไรเพิ่ม จึงพอใจมาก

  • แม้จะไม่เกี่ยวกับ Starship โดยตรง แต่ฉันรำคาญอาการที่เวลาใน zsh prompt กด Enter แล้วเคอร์เซอร์จะขยับวูบไปต้นบรรทัดชั่วครู่เหมือนเกิด “แฟลช”
    ถ้าเป็นพรอมป์ต์ที่เร็วมากจะเห็นน้อยลง แต่ถ้ามีอะไรทำงานในพรอมป์ต์แม้เพียงเล็กน้อย อาการนี้จะสังเกตได้ชัดมาก
    พบเหมือนกันในหลาย terminal (gnome-terminal, wezterm, kitty, alacritty, xterm)
    มีเพียง urxvt เท่านั้นที่ไม่เกิดปัญหานี้
    ดูได้ที่ วิดีโอสาธิต
    เลยสงสัยว่าสาเหตุและวิธีหลีกเลี่ยงอาการแฟลชนี้คืออะไร

  • ถ้าทุกครั้งที่พรอมป์ต์เรนเดอร์ ซึ่งเกิดทุก 100ms ต้องไปเช็กข้อมูลอย่าง git status ที่ไม่ค่อยมีประโยชน์ ก็จะกลายเป็นการลดทอนประสิทธิภาพแบบมองไม่เห็น
    terminal ควรเป็นเครื่องมือช่วยจำที่ตอบสนองไว และควรหลีกเลี่ยงสิ่งที่เป็นแค่ของตกแต่งเกินจำเป็น
    ปัญหาคือเรามักจริงจังกับความเร็วในการรันโค้ด แต่กลับใจกว้างกับ latency ตอนพิมพ์ของตัวเอง

    • Starship เร็วมากจริง ๆ
      ใช้เวลาเพียงไม่กี่ ms ในการรวบรวมข้อมูลที่ต้องการ และควบคุมได้ง่ายว่าจะดึงข้อมูลอะไรบ้าง
      เครื่องมืออื่นที่เคยใช้มักมีอาการหน่วงที่รู้สึกได้จนรำคาญอยู่เสมอ แต่เวลาใช้ Starship ความต่างที่สัมผัสได้ชัดเจนมาก

    • 100ms ที่มนุษย์รู้สึก กับ 100ms ในการ optimization ของ CPU เป็นคนละเรื่องกันโดยสิ้นเชิง
      สำหรับฉัน มันทำให้คิดว่า ถ้าพรอมป์ต์ใช้เวลา 100ms เพื่อแสดง git branch หรือสถานะ แล้วทำให้ “flow” สะดุด เทียบกับเวลาที่ฉันใช้พิมพ์คำสั่งเองนานกว่านั้น อะไรคือสิ่งที่ควร optimize มากกว่ากัน
      ความสะดวกบางอย่างที่แลกมาด้วยเวลาไม่กี่ ms นั้นถือว่าคุ้มค่าพอจะยอมรับได้
      สุดท้ายก็เป็นการหาสมดุลระหว่างความสะดวกกับความมินิมอล
      ทั้งความมินิมอลสุดโต่งและการตกแต่งมากเกินไปต่างก็อาจนำไปสู่ความไม่มีประสิทธิภาพได้เหมือนกัน

    • เพราะรำคาญ latency แบบนี้ ฉันเลยแพตช์ terminal kitty เพื่อย้ายพรอมป์ต์ Starship ไปไว้ใน status bar ด้านล่างแบบเดียวกับ modeline ของ vim หรือ emacs
      modeline จะอัปเดตแบบ asynchronous ทำให้การตอบสนองของพรอมป์ต์เร็วมาก
      ข้อเสียคือจำเป็นต้องแพตช์ kitty เอง และฉันก็ยังไม่ได้ทดสอบนอกเหนือจากสภาพแวดล้อม Linux ส่วนตัว
      ดูได้ที่ โปรเจกต์แพตช์ที่เกี่ยวข้อง

    • สงสัยว่าเครื่องมือพรอมป์ต์จะสามารถทำงานแบบ TUI ได้หรือไม่ คือหลังจากคืนผลลัพธ์การแสดงพรอมป์ต์ครบแล้ว ก็ยังค่อย ๆ แก้ไขพื้นที่พรอมป์ต์แบบ asynchronous ต่อได้ (เช่น kubectl, git, aws cli มาเติมข้อมูลทีหลังอีก 200ms)
      ถ้าทำได้ ผู้ใช้ก็จะพิมพ์คำสั่งถัดไปได้ทันทีโดยไม่ต้องรอ และข้อมูลเสริมก็จะค่อย ๆ ปรากฏขึ้นภายหลังอย่างเป็นธรรมชาติ

    • ฉันคิดว่าบางทีการ optimize input latency ของพรอมป์ต์อาจยากขึ้นเพราะมี layer การใช้งานเพิ่มขึ้นเรื่อย ๆ มากกว่าจะเป็นเรื่อง optimize การรันโค้ดอย่างเดียว

  • ตอนเข้าเว็บไซต์ทางการ ฉันรู้สึกว่ามันยังอธิบายไม่ชัดพอว่าทำไมควรใช้ Starship
    ช่วงหลังฉันคัสตอมพรอมป์ต์ให้มองเห็นข้อมูลต่อไปนี้ได้ในคราวเดียว

    <pre><code>- ผลลัพธ์ของคำสั่งล่าสุด (สี: เขียว แดง ม่วง)
  • user@host:currentDirectory
  • (ถ้าอยู่ใน repo) branch ปัจจุบันและสรุป git status รวมถึง background jobs</code></pre>
    ถ้าคำสั่งล่าสุดสำเร็จจะแสดงเป็นสีเขียว ถ้าล้มเหลวจะแสดงเป็นสีแดง และถ้าถูกยกเลิกจะแสดงเป็นสีม่วง
    ฉันอาจจะเป็นผู้ใช้กลุ่มเป้าหมายของพวกเขา แต่จากหน้าโฮมเพจ ฉันยังไม่ได้รับการสื่อสารที่ชัดเจนว่าเหตุผลที่ควรใช้คืออะไร และมันปรับปรุงอะไรให้ดีขึ้นบ้าง