คำถามติดแท็ก posix

POSIX เป็นตัวย่อสำหรับ Portable Operating System Interface ซึ่งเป็นตระกูลมาตรฐานที่ IEEE กำหนดไว้สำหรับการรักษาความเข้ากันได้ระหว่างระบบปฏิบัติการ

4
$ VAR เทียบกับ $ {VAR} และเพื่อพูดหรือไม่พูด
ฉันเขียนได้ VAR=$VAR1 VAR=${VAR1} VAR="$VAR1" VAR="${VAR1}" ผลลัพธ์ที่ได้สำหรับฉันทุกคนดูเหมือนจะเหมือนกัน ทำไมฉันต้องเขียนอย่างใดอย่างหนึ่ง? เหล่านี้ไม่ใช่พกพา / POSIX?

4
POSIX คืออะไร
ฉันเห็น POSIX พูดถึงบ่อยครั้งและทุกที่และฉันคิดว่ามันเป็นมาตรฐานของระบบปฏิบัติการยูนิกซ์พื้นฐาน .. จนกระทั่งฉันสังเกตเห็นข้อความที่ตัดตอนมาต่อไปนี้บนหน้า Wikipedia: The Open Group เปิด Group มีชื่อเสียงมากที่สุดในขณะที่ร่างกายได้รับการรับรองสำหรับเครื่องหมายการค้า UNIX และสิ่งพิมพ์ของมาตรฐานทางเทคนิคสเปก Unix เดี่ยว , ซึ่งทอดตัวมาตรฐาน POSIX และเป็นความหมายอย่างเป็นทางการของระบบยูนิกซ์ หากคำจำกัดความอย่างเป็นทางการของระบบ UNIX เป็นส่วนเสริมของ POSIX แล้ว POSIX คืออะไร ,,, ดูเหมือนว่ามันจะเป็นมาตรฐานของโลกยูนิกซ์ แต่ฉันไม่รู้ว่ามันเข้ากับภาพรวมได้อย่างไร
139 posix  standard 

5
ความแตกต่างระหว่าง“ function foo () {}” และ“ foo () {}”
ฉันสามารถกำหนดbashฟังก์ชั่นการใช้หรือละเว้นfunctionคำหลักได้ มีความแตกต่างหรือไม่? #!/bin/bash function foo() { echo "foo" } bar() { echo "bar" } foo bar ทั้งการเรียกใช้ฟังก์ชันfooและbarประสบความสำเร็จและฉันไม่เห็นความแตกต่างเลย ดังนั้นฉันสงสัยว่ามันเป็นเพียงเพื่อปรับปรุงการอ่านหรือมีบางสิ่งที่ฉันขาดหายไป ... BTW ในเชลล์อื่น ๆ เช่นdash(เชื่อม/bin/shโยงกับdashเดเบียน / Ubuntu) มันล้มเหลวเมื่อใช้functionคำหลัก
96 bash  shell  function  posix 

5
รายงานความคืบหน้า / ข้อมูลการบันทึกเป็นของ stderr หรือ stdout หรือไม่?
มี POSIX, GNU อย่างเป็นทางการหรือแนวทางอื่น ๆ หรือไม่ว่ารายงานความคืบหน้าและข้อมูลการบันทึก (สิ่งต่าง ๆ เช่น "Doing foo; foo done") ควรพิมพ์ออกมาหรือไม่? โดยส่วนตัวแล้วฉันมักจะเขียนถึง stderr เพื่อที่ฉันจะสามารถเปลี่ยนเส้นทาง stdout และรับเอาท์พุทจริงของโปรแกรมเท่านั้น ฉันเพิ่งบอกว่านี่ไม่ใช่วิธีปฏิบัติที่ดีเนื่องจากรายงานความคืบหน้าไม่ใช่ข้อผิดพลาดจริง ๆ และควรพิมพ์เฉพาะข้อความข้อผิดพลาดไปยัง stderr ทั้งสองตำแหน่งมีเหตุผลและแน่นอนว่าคุณสามารถเลือกอย่างใดอย่างหนึ่งขึ้นอยู่กับรายละเอียดของสิ่งที่คุณกำลังทำอยู่ แต่ฉันอยากจะรู้ว่ามีมาตรฐานที่ยอมรับกันโดยทั่วไปสำหรับเรื่องนี้หรือไม่ ฉันไม่สามารถค้นหากฎเฉพาะใน POSIX มาตรฐานการเข้ารหัสของ GNU หรือรายการแนวทางปฏิบัติที่ดีที่สุดอื่น ๆ เรามีคำถามที่คล้ายกันสองสามข้อ แต่พวกเขาไม่ได้แก้ไขปัญหาที่แน่นอนนี้: เมื่อใดที่จะใช้การเปลี่ยนเส้นทางไปยัง stderr ในเชลล์สคริปต์ : คำตอบที่ได้รับการยอมรับแสดงให้เห็นสิ่งที่ฉันมักจะทำเอาท์พุทสุดท้ายของโปรแกรมไว้ที่ stdout และทุกอย่างจะเป็น stderr อย่างไรก็ตามนี่เป็นเพียงความเห็นของผู้ใช้แม้ว่าจะได้รับการสนับสนุนจากการขัดแย้ง ข้อความการใช้งานควรไปที่ stderr หรือ stdout หรือไม่ : นี่เป็นข้อความเฉพาะสำหรับช่วยเหลือข้อความ แต่อ้างอิงมาตรฐานการเข้ารหัสของ …
75 posix  stdout  gnu  stderr  standard 

3
ฉันจะทดสอบความสอดคล้องของ POSIX ของเชลล์สคริปต์ได้อย่างไร
เมื่อพิจารณาว่า POSIX เป็นสิ่งที่ใกล้เคียงกับมาตรฐานทั่วไปมากที่สุดในบรรดา unices ทั้งหมดฉันสนใจที่จะรู้ว่ามีเชลล์ที่รองรับมันโดยเฉพาะหรือไม่ ในขณะที่เชลล์ที่ทันสมัยส่วนใหญ่ให้การสนับสนุน POSIX (และจะเรียกใช้สคริปต์ที่สอดคล้องกับ POSIX โดยไม่มีปัญหาใด ๆ ) พวกมันทำงานได้ไม่ดีในการชี้ให้เห็นคุณลักษณะที่ไม่เข้ากันได้ มีเชลล์ที่ใช้ POSIX และ POSIX เท่านั้นในลักษณะที่มันจะโยนข้อผิดพลาดสำหรับคุณสมบัติที่ไม่เข้ากันได้หรือไม่? แก้ไขฉันต้องการชี้แจงว่าฉันไม่ได้ขอคำแนะนำทั่วไปสำหรับการเขียนเชลล์สคริปต์แบบพกพา คำถามที่เกี่ยวข้องพูดถึงในความคิดเห็นที่ครอบคลุมนี้ ฉันคิดว่าคำถามนี้เมื่อฉันพบว่าbashมี--posixตัวเลือก แต่เพียงเพื่อค้นพบว่ามันมีผลต่อพฤติกรรมการทำให้มีลักษณะเฉพาะบางอย่างซึ่งไม่ใช่สิ่งที่ฉันกำลังมองหา

3
ประเด็นของคำสั่งภายนอก `cd` คืออะไร?
ตามที่อ้างถึงในคำตอบที่ดีนี้ระบบ POSIX มีไบนารี่ภายนอกcdเพิ่มเติมจากเชลล์บิวด์อิน บน OS X 10.8 /usr/bin/cdมัน คุณไม่สามารถใช้มันเหมือน builtin ได้cdเพราะมันจะออกมาทันทีหลังจากเปลี่ยนไดเรกทอรีการทำงานของมันเอง มันมีจุดประสงค์อะไร

5
แบบพกพาเป็นอย่างไร / dev / stdin, / dev / stdout และ / dev / stderr?
บางครั้งผมต้องระบุเส้นทาง "เทียบเท่า" ของหนึ่งในลำธาร IO มาตรฐาน ( stdin, stdout, stderr) ตั้งแต่ 99% ของเวลาที่ฉันทำงานกับ Linux ฉันแค่เตรียมที่/dev/จะรับ/dev/stdinฯลฯ และสิ่งนี้ " ดูเหมือนจะทำสิ่งที่ถูกต้อง" แต่สิ่งหนึ่งที่ฉันไม่สบายใจเกี่ยวกับเหตุผลดังกล่าวอยู่เสมอ (เพราะแน่นอน "ดูเหมือนว่าจะทำงาน" จนกว่าจะไม่) นอกจากนี้ฉันไม่มีความรู้สึกที่ดีสำหรับวิธีการพกพาในการซ้อมรบนี้ ดังนั้นฉันมีคำถามสองสามข้อ: ในบริบทของลินุกซ์มันมีความปลอดภัย (ใช่ / ไม่ใช่) จะถือเอาstdin, stdoutและstderrด้วย/dev/stdin, /dev/stdoutและ /dev/stderr? โดยทั่วไปแล้วความเท่าเทียมนี้ " พกพาได้อย่างเพียงพอ" หรือไม่? ฉันไม่พบการอ้างอิง POSIX ใด ๆ

1
'rm. *' เคยลบไดเรกทอรีหลักหรือไม่
นิพจน์.*ถูกขยายโดย bash เพื่อรวมไดเรกทอรีปัจจุบันและพาเรนต์: $ ls -la total 2600 drwxrwxrwx 2 terdon terdon 2162688 Sep 10 16:22 . drwxr-xr-x 142 terdon terdon 491520 Sep 10 15:34 .. -rw-r--r-- 1 terdon terdon 0 Sep 10 16:22 foo $ echo .* . .. ถ้าฉันใช้rm -rf .*Debian โดยใช้ GNU bash version 4.2.36(1)-releaseและrmจากrm (GNU coreutils) …
53 shell  wildcards  rm  posix 

3
ความแตกต่างระหว่าง POSIX ข้อมูลจำเพาะ UNIX เดี่ยวและข้อมูลจำเพาะของ Open Group Base?
ความแตกต่างระหว่าง POSIX, ข้อมูลจำเพาะ UNIX เดี่ยวและข้อมูลจำเพาะของOpen Group Baseคืออะไร ฉันคิดว่าจุดประสงค์ของพวกเขาคือเพื่อพิจารณาว่าระบบปฏิบัติการเป็น Unix หรือไม่?
53 posix 

1
เมื่อใดและอย่างไร double-dash (-) ถูกนำมาใช้เป็นจุดสิ้นสุดของตัวเลือกตัวคั่นใน Unix / Linux
ฉันไม่คิดว่าเปลือก / สาธารณูปโภคในประวัติศาสตร์ Unix หรือในสิ่งที่เป็น "ล่าสุด" เป็น4.4BSDสนับสนุนการใช้สองเส้นประ (หรือสองยัติภังค์ติดต่อกัน) ในฐานะที่เป็นส่วนท้ายของตัวเลือกตัวคั่น ด้วยFreeBSDคุณสามารถดูตัวอย่างข้อความที่แนะนำในrm manpagesด้วย2.2.1 รีลีส (1997) แต่นี่เป็นเพียงเอกสารประกอบสำหรับคำสั่งเดียว ดูGNU fileutils changelog ที่เก่าแก่ที่สุดที่ฉันสามารถหาได้ฉันเห็นสิ่งนี้1 (เปลี่ยนแปลงเล็กน้อย): Tue Aug 28 18:05:24 1990 David J. MacKenzie (djm at albert.ai.mit.edu) * touch.c (main): Don't interpret first non-option arg as a <--- time if `--' is given (POSIX-required kludge). * touch.c: …
49 history  posix  gnu  arguments 

8
เหตุใดยูทิลิตี้บังคับ POSIX จึงไม่ได้สร้างไว้ในเชลล์?
จุดประสงค์ของคำถามนี้คือเพื่อตอบสนองความอยากรู้อยากเห็นไม่ใช่เพื่อแก้ปัญหาการคำนวณโดยเฉพาะ คำถามคือ: เหตุใดยูทิลิตี้บังคับ POSIX จึงไม่ได้สร้างอยู่ในการใช้งานเชลล์? ตัวอย่างเช่นฉันมีสคริปต์ที่อ่านไฟล์ข้อความเล็ก ๆ น้อย ๆ และตรวจสอบว่ามีการฟอร์แมตอย่างถูกต้อง แต่ใช้เวลา 27 วินาทีในการเรียกใช้บนเครื่องของฉันเนื่องจากมีการจัดการสตริงจำนวนมาก การจัดการสตริงนี้สร้างกระบวนการใหม่นับพันโดยเรียกโปรแกรมอรรถประโยชน์ต่าง ๆ ดังนั้นความเชื่องช้า ผมค่อนข้างมั่นใจว่าถ้าบางส่วนของสาธารณูปโภคที่ถูกสร้างขึ้นในคือgrep, sed, cut, trและexprแล้วสคริปต์ที่จะวิ่งในครั้งที่สองหรือน้อยกว่า (ขึ้นอยู่กับประสบการณ์ของผมใน C) ดูเหมือนว่าจะมีหลายสถานการณ์ที่การสร้างโปรแกรมอรรถประโยชน์เหล่านี้จะสร้างความแตกต่างระหว่างว่าโซลูชันในเชลล์สคริปต์มีประสิทธิภาพที่ยอมรับได้หรือไม่ เห็นได้ชัดว่ามีเหตุผลที่เลือกที่จะไม่สร้างยูทิลิตี้เหล่านี้ในตัวอาจมียูทิลิตี้หนึ่งเวอร์ชันในระดับระบบเพื่อหลีกเลี่ยงการมียูทิลิตี้รุ่นนั้นไม่เท่ากันหลายรุ่น ฉันไม่สามารถคิดด้วยเหตุผลอื่น ๆ อีกมากมายที่จะรักษาค่าใช้จ่ายในการสร้างกระบวนการใหม่จำนวนมากและ POSIX กำหนดเพียงพอเกี่ยวกับยูทิลิตี้ที่ดูเหมือนว่าปัญหาจะมีการใช้งานที่แตกต่างกันไม่มาก ไม่ขัดขืน อย่างน้อยก็ไม่เป็นปัญหาใหญ่เท่าความไร้ประสิทธิภาพของการมีกระบวนการมากมาย

7
การทดสอบหรือ [หรือ [พกพาได้มากกว่าระหว่างเชลล์ bash และระหว่างเชลล์อื่นหรือไม่?
ฉันเห็นฉันสามารถทำ $ [ -w /home/durrantm ] && echo "writable" writable หรือ $ test -w /home/durrantm && echo "writable" writable หรือ $ [[ -w /home/durrantm ]] && echo "writable" writable ฉันชอบใช้ไวยากรณ์ที่สาม พวกมันเทียบเท่ากันในทุกวิถีทางและสำหรับคดีลบและคดีขอบ มีความแตกต่างในการพกพาเช่นระหว่างทุบตีบน Ubuntu และบน OS X หรือรุ่นทุบตีเก่า / ใหม่กว่าเช่นก่อน / หลัง 4.0 และพวกเขาทั้งสองขยายการแสดงออกในลักษณะเดียวกันหรือไม่

4
ทำไมระบบ UNIX / POSIX จึงเรียกการ namings ว่าอ่านไม่ออก?
เป็นเหตุผลที่จะใช้ชื่อเรียกระบบ untelling เช่นอะไรtimeและcreatแทนgetCurrentTimeSecsและcreateFileหรืออาจจะเหมาะสมกว่าบน Unix และget_current_time_secs create_fileซึ่งนำฉันไปยังจุดต่อไป: ทำไมบางคนควรต้องการบางสิ่งบางอย่างเช่นcfsetospeedโดยไม่มีกรณีอูฐหรืออย่างน้อยก็ขีดเพื่อให้สามารถอ่านได้? แน่นอนว่าการโทรจะมีตัวอักษรมากขึ้น แต่เราทุกคนรู้ว่าการอ่านโค้ดมีความสำคัญมากกว่าใช่มั้ย

3
ทำไมบางแอปพลิเคชันใช้ ~ / .config / appname สำหรับข้อมูลการกำหนดค่าของพวกเขาในขณะที่คนอื่นใช้ ~ / .appname?
ฉันสังเกตเห็นว่าบางแอปพลิเคชันนำไฟล์การตั้งค่าไปใช้~/.config/appnameขณะที่บางแอปพลิเคชันใช้~/.appname(ในแบบคลาสสิก AFAIK) สำหรับสิ่งนี้ ความรู้สึกในความแตกต่างนี้และสิ่งที่จะดีกว่าที่จะพิจารณาสำหรับการใช้งานของฉัน? อัปเดต: ดูเหมือนว่า (ค่าเริ่มต้น XUbuntu 11.10) ของฉัน $ XDG_CONFIG_HOME ถูกตั้งค่าเป็น~/และแอปพลิเคชั่นส่วนใหญ่ในระบบของฉัน (เช่น Mozilla Firefox, Adobe Flash Player, Midnight Commander, Opera, Wine, ฯลฯ ) ปฏิบัติตามสิ่งนี้ แต่ยังมีแอปพลิเคชั่นมากมาย (เช่น Compiz, Deadbeef, VLC, Qt Creator, Google Chrome, XFCE และอื่น ๆ ) ที่ใช้~/.config/แทน อีกสิ่งที่น่าสงสัยก็คือไดเรกทอรีที่อยู่ใน~/.config/นั้นไม่ถูกซ่อน (ไม่มีจุดในชื่อ) - ไม่ใช่แอปพลิเคชันที่คาดว่าจะมีชื่อคงที่โดยไม่ขึ้นอยู่กับตำแหน่ง (ค่า $ XDG_CONFIG_HOME)

7
มีการโต้แย้งหลายครั้งใน shebang
ฉันสงสัยว่ามีวิธีทั่วไปในการส่งตัวเลือกหลายตัวไปยังโปรแกรมที่เรียกใช้งานได้ผ่านทางสาย shebang ( #!) ผมใช้ NixOS และส่วนแรกของ shebang ในสคริปต์ใด ๆ /usr/bin/envที่ฉันเขียนมักจะ ปัญหาที่ฉันพบคือทุกสิ่งที่เกิดขึ้นหลังจากนั้นถูกตีความว่าเป็นไฟล์หรือไดเรกทอรีเดียวโดยระบบ ตัวอย่างเช่นสมมติว่าฉันต้องการเขียนสคริปต์ที่จะดำเนินการโดยbashในโหมด posix วิธีที่ไร้เดียงสาของการเขียน Shebang จะเป็น: #!/usr/bin/env bash --posix แต่พยายามที่จะรันสคริปต์ผลลัพธ์จะสร้างข้อผิดพลาดต่อไปนี้: /usr/bin/env: ‘bash --posix’: No such file or directory ฉันทราบเกี่ยวกับโพสต์นี้แต่ฉันสงสัยว่ามีวิธีการทั่วไปที่สะอาดกว่าหรือไม่ แก้ไข : ฉันรู้ว่าสำหรับสคริปต์Guileมีวิธีการบรรลุสิ่งที่ฉันต้องการบันทึกไว้ในส่วน 4.3.4ของคู่มือ: #!/usr/bin/env sh exec guile -l fact -e '(@ (fac) main)' -s "$0" "$@" !# เคล็ดลับที่นี่ก็คือบรรทัดที่สอง (เริ่มต้นด้วยexec) …

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