วิธีการติดตั้ง executables

บางครั้งฉันพบซอฟต์แวร์ที่ไม่มีใน.debหรือ.rpmเป็นเพียงไฟล์ปฏิบัติการ
ยกตัวอย่างเช่นVisual Studio รหัส , WebStormหรือKerbal อวกาศ Programm

สำหรับคำถามนี้ฉันจะใช้ Visual Studio Code เป็นจุดอ้างอิง

ซอฟต์แวร์มีให้ในรูปแบบแพ็คเกจซิป
เมื่อขยายไฟล์ฉันทิ้งให้อยู่กับโฟลเดอร์ที่เรียกว่าที่มีการปฏิบัติการที่มีชื่อว่าVSCode-linux-x64 ฉันสามารถดับเบิลคลิกหรือชี้ไปที่จุดนั้นด้วยเทอร์มินัลของฉันเพื่อเรียกใช้งาน อย่างไรก็ตามฉันต้องการทราบว่ามีวิธีที่เหมาะสมในการติดตั้งแอปพลิเคชันนี้หรือไม่ Code
Code/home/user/Downloads/VSCode-linux-x64/Code

สิ่งที่ฉันต้องการบรรลุคือ:

• ที่เดียวที่ฉันสามารถใส่แอพพลิเคชั่น / ซอฟต์แวร์ทั้งหมดที่มีให้ในลักษณะนี้ (ปฏิบัติการ)
• การสนับสนุนเทอร์มินัล (นั่นหมายถึงตัวอย่างเช่น: ฉันสามารถเขียนvscodeจากโฟลเดอร์ใด ๆ ในเทอร์มินัลของฉันและมันจะรัน Visual Studio Code

ข้อมูลเพิ่มเติม:

• สภาพแวดล้อมเดสก์ทอป: Gnome3
• ระบบปฏิบัติการ: Debian

แก้ไข:
ฉันตัดสินใจที่จะให้ @kba คำตอบเพราะวิธีการของเขาทำงานได้ดีขึ้นด้วยโซลูชั่นสำรองของฉันและนอกจากนั้น การมีสคริปต์ที่ใช้งานไบนารีจะช่วยให้คุณสามารถเพิ่มอาร์กิวเมนต์ได้
แต่เพื่อความยุติธรรมวิธีการของ @John WH Smith นั้นดีเท่ากับ @ kba's

ในการเรียกโปรแกรมตามชื่อเชลล์ค้นหาไดเร็กทอรีใน$PATHตัวแปรสภาพแวดล้อม ใน Debian ค่าเริ่มต้น$PATHสำหรับผู้ใช้ของคุณควรรวม/home/YOUR-USER-NAME/bin(เช่น~/bin)

ก่อนอื่นตรวจสอบให้แน่ใจว่ามีไดเรกทอรี~/binอยู่หรือสร้างขึ้นมาหากไม่มี:

mkdir -p ~/bin

คุณสามารถ symlink ไบนารีไปยังไดเรกทอรีนั้นเพื่อให้เปลือก:

mkdir -p ~/bin
ln -s /home/user/Downloads/VSCode-linux-x64/Code ~/bin/vscode

ที่จะช่วยให้คุณสามารถรันvscodeบนบรรทัดคำสั่งหรือจากตัวเรียกใช้งานคำสั่ง

หมายเหตุ: คุณยังสามารถคัดลอกไบนารีไปยัง$PATHไดเรกทอรี แต่อาจทำให้เกิดปัญหาได้หากพวกเขาขึ้นอยู่กับเส้นทางสัมพัทธ์

โดยทั่วไปแล้วมันจะดีกว่าเสมอที่จะติดตั้งซอฟต์แวร์อย่างถูกต้องโดยใช้วิธีการที่ได้รับจากระบบปฏิบัติการ (apt-get, แพ็คเกจ deb) หรือเครื่องมือสร้างของโครงการซอฟต์แวร์ วิธีนี้จะช่วยให้มั่นใจได้ว่าเส้นทางที่ขึ้นต่อกัน (เช่นสคริปต์เริ่มต้นหน้าคนการกำหนดค่า ฯลฯ ) ได้รับการตั้งค่าอย่างถูกต้อง

Update:สะท้อนความเห็นของThomas DickeyและFaheem Mitha คำตอบที่ฉันมักจะทำกับซอฟต์แวร์ที่มาในรูปแบบ tarball ที่มีไบนารีระดับบนสุดและคาดว่าจะเรียกใช้จากที่นั่น:

วางไว้ในสถานที่ที่มีสติ (ในคำสั่งของมาตรฐานการปฏิบัติ/opt, /usr/localหรือโฟลเดอร์ในไดเรกทอรีที่บ้านของคุณเช่น~/build) และสร้างเสื้อคลุมสคริปต์ที่ปฏิบัติการใน$PATHสถานที่ตั้ง (เช่น/usr/local/binหรือ~/bin) ที่เปลี่ยนแปลงไปยังสถานที่และดำเนินการไบนารี:

#/bin/sh
cd "$HOME/build/directory"
exec ./top-level-binary "$@"

เนื่องจากสิ่งนี้เลียนแบบการเปลี่ยนแปลงไปยังไดเรกทอรีนั้นและดำเนินการไบนารีด้วยตนเองจึงทำให้ง่ายต่อการแก้ไขปัญหาเช่นเส้นทางที่ไม่มีอยู่

ตามTLDP , /optอาจจะเป็นสถานที่ที่ดีสำหรับชนิดของซอฟต์แวร์นี้ ฉันใช้มันเพื่อเก็บเครื่องมือที่เกี่ยวข้องกับเครื่องพิมพ์และ Skype "แบบไดนามิก" (ดังที่ kba กล่าวว่าสามารถทำได้ "การสนับสนุนเทอร์มินัล" โดยการตั้งค่าPATHตัวแปรตาม)

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

อีกเหตุผลที่ฉันเลือก/optคือเพราะมันมักจะมีความหมายสำหรับบุคคลที่สามรหัสอิสระซึ่งไม่พึ่งพาไฟล์ใด ๆ นอก/opt/'package'ไดเรกทอรี (และoptไดเรกทอรีอื่น ๆเช่น/etc/opt)

ภายใต้สถานการณ์ที่ไม่มีไฟล์แพ็กเกจอื่น ๆ ที่จะมีอยู่นอกลำดับชั้น / opt, / var / opt และ / etc / opt ยกเว้นสำหรับไฟล์แพ็กเกจที่ต้องอยู่ในตำแหน่งเฉพาะภายในแผนผังระบบไฟล์เพื่อให้ทำงานได้อย่างถูกต้อง [... ] โดยทั่วไปข้อมูลทั้งหมดที่จำเป็นในการสนับสนุนแพ็คเกจในระบบจะต้องแสดงอยู่ภายใน / opt / 'package' รวมถึงไฟล์ที่ต้องการคัดลอกไปยัง / etc / opt / 'package' และ / var / opt / ' แพ็คเกจ 'รวมถึงไดเรกทอรีที่จองไว้ใน / opt

ข้อดีอย่างหนึ่งของการปล่อยซอร์สโค้ดคือคนจะได้รับการกำหนดค่ากระบวนการรวบรวมให้เส้นทางไลบรารี / ส่วนหัวที่กำหนดเองตามลักษณะเฉพาะของระบบ เมื่อผู้พัฒนาตัดสินใจที่จะปล่อยรหัสในรูปแบบที่ปฏิบัติการข้อดีนั้นจะหายไป IMHO ณ จุดนี้ผู้พัฒนาไม่ได้รับอนุญาตให้สมมติว่าการพึ่งพาโปรแกรมของเขา / เธอจะสามารถใช้งานได้ (ซึ่งเป็นเหตุผลว่าทำไมทุกอย่างควรได้รับการบรรจุพร้อมกับปฏิบัติการ)

แพคเกจใด ๆ ที่จะติดตั้งที่นี่จะต้องค้นหาไฟล์สแตติก (เช่น. แบบอักษรพิเศษภาพตัดปะไฟล์ฐานข้อมูล) ในไดเรกทอรี / แยก / opt / 'แพคเกจ' หรือ / opt / 'ผู้ให้บริการ' (คล้ายกับวิธีที่ Windows จะติดตั้ง ซอฟต์แวร์ใหม่ไปยังแผนผังไดเรกทอรีของตัวเอง C: \ Windows \ Progam Files \ "ชื่อโปรแกรม") โดยที่ 'แพ็คเกจ' เป็นชื่อที่อธิบายถึงแพคเกจซอฟต์แวร์และ 'ผู้ให้บริการ' เป็นชื่อที่ลงทะเบียน LANANA ของผู้ให้บริการ

สำหรับข้อมูลเพิ่มเติมฉันยังอยากจะขอแนะนำให้อ่านนี้อื่น ๆ U & L คำถามซึ่งข้อเสนอที่มีความแตกต่าง betwen และ/opt /usr/localฉันจะหลีกเลี่ยงเป็นการส่วนตัว/usr/localในกรณีนี้โดยเฉพาะถ้าฉันไม่ใช่คนที่สร้างโปรแกรมที่ฉันกำลังติดตั้ง

เป็นไปได้ทั้งหมดและอันที่จริงแล้วค่อนข้างง่ายในการสร้างแพ็คเกจไบนารีการกระจายจากไฟล์ zip zip หรือ tarball ดังตัวอย่างใน Visual Studio Code ของคุณ

ใช่แพคเกจไบนารีการกระจาย Linux เช่นdebs และrpms นั้นสร้างขึ้นจากแหล่งที่มา แต่ไม่จำเป็นต้องเป็น และมักเป็นไปได้ (แม้ว่าจะไม่เสมอไป) ในการจัดเรียงสิ่งต่าง ๆ ให้กับแพคเกจไบนารีการกระจายผลลัพธ์ที่ติดตั้งสิ่งต่าง ๆ ในสถานที่ "เหมาะสม" เพื่อให้สอดคล้องกับนโยบายการกระจาย

ในกรณีของ tarball ที่เป็นกรรมสิทธิ์แบบสุ่มหากมีวิธีในการติดตั้งซอฟต์แวร์อย่างถูกต้องเช่นเป้าหมายการติดตั้งใน makefile จะสามารถใช้กับเครื่องจักรบรรจุภัณฑ์แบบกระจายได้ มิฉะนั้นสิ่งนี้อาจเกี่ยวข้องกับการแมปไฟล์ "ด้วยตนเอง" ไปยังตำแหน่ง "ขวา" ซึ่งอาจเป็นงานจำนวนมาก ในขณะที่สร้างแพคเกจดังกล่าวอาจดูเหมือนเป็นเรื่องแปลกที่จะทำมันจะยังคงมีหนึ่งในประโยชน์ที่สำคัญของการจัดการแพคเกจคือการติดตั้งที่สะอาดและถอนการติดตั้ง และแน่นอนว่าแพคเกจดังกล่าวจะไม่ได้รับการยอมรับในการแจกจ่าย Linux ใด ๆ ที่คุ้มค่ากับชื่อ แต่นั่นไม่ใช่คำถามของคุณ

ฉันเคยเห็นซอฟต์แวร์ที่ส่งมาเป็นแบบไบนารีที่ปฏิบัติการได้และไม่มีอะไรอื่นอีกแล้วและฉันก็จะสงสัยอย่างตรงไปตรงมา หากไม่มีอะไรอย่างน้อยฉันก็คาดหวังREADME(พร้อมคำแนะนำในการติดตั้ง) และ a LICENSEไปพร้อมกับมัน ที่ถูกกล่าวว่า ...

สถานที่ปกติที่ไบนารีที่ติดตั้งภายในไม่ได้บริหารโดยผู้จัดการแพคเกจ distro /usr/local/binที่จะถูกเก็บไว้เป็น คุณสามารถวางไว้ที่นั่นและเนื่องจากไดเรกทอรีนั้น (หรือควร) อยู่ในคุณแล้ว$PATHคุณสามารถใช้งานซอฟต์แวร์ได้โดยพิมพ์ชื่อที่บรรทัดคำสั่ง

โดยปกติแล้วซอฟต์แวร์ควรมี manpage (ซอฟต์แวร์ที่ไม่มีเอกสารที่ไม่ดีใช่มั้ย) ซึ่งเข้ามา/usr/local/manและอาจมีไฟล์สนับสนุนบางอย่างเช่นการแปลเป็นภาษาอื่นและปลั๊กอินที่อาจเข้า/usr/local/shareหรือ/usr/local/libออกเป็นต้น ด้วยเหตุนี้ซอฟต์แวร์ที่ไม่ได้จัดส่งให้เป็นแพ็คเกจเช่น.debหรือ.rpmมักจะมาพร้อมกับตัวติดตั้งที่ทำให้ทุกอย่างถูกที่ make installเมื่อคุณติดตั้งจากแหล่งที่มาที่มักจะ