Tại sao nguồn mặc định của Ubuntu ~ / .profile ~ / .bashrc?


30

Đây là nội dung của cổ phiếu ~/.profileđi kèm với 13.10 của tôi (dòng nhận xét đã bị xóa):

if [ -n "$BASH_VERSION" ]; then
    if [ -f "$HOME/.bashrc" ]; then
    . "$HOME/.bashrc"
    fi
fi

if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

Điều này được kế thừa từ Debian nhưng tại sao Canonical quyết định giữ nó? Theo như tôi biết, đó không phải là cách * nix tiêu chuẩn và tôi đã thấy nhiều hệ thống khác nhau không xảy ra, vì vậy tôi cho rằng chúng phải có lý do chính đáng. Điều này có thể gây ra hành vi không mong muốn khi chạy shell đăng nhập (chẳng hạn như khi sshing vào máy chẳng hạn) mà người dùng sẽ không mong muốn có ~/.bashrcnguồn gốc.

Lợi ích duy nhất tôi có thể nghĩ đến là không nhầm lẫn người dùng với nhiều tệp khởi động và cho phép họ chỉnh sửa .bashrcmột mình và đọc mà không phân biệt loại vỏ. Tuy nhiên, đó là một lợi ích đáng ngờ vì thường hữu ích khi có các cài đặt khác nhau để đăng nhập và cho các vỏ tương tác và điều này ngăn bạn làm như vậy. Ngoài ra, shell đăng nhập thường không chạy trong môi trường đồ họa và điều đó có thể gây ra lỗi và cảnh báo và sự cố (oh my!) Tùy thuộc vào những gì bạn đã đặt trong các tệp đó.

Vậy tại sao Ubuntu làm điều này, tôi còn thiếu gì?


Tại sao sẽ -n "$BASH_VERSION"là sự thật bên ngoài của bash?
Elliott Frisch

@ElliottFrisch nó sẽ không được. Câu hỏi của tôi là tại sao .profilenguồn .bashrc, đó không phải là trường hợp trong tất cả các phiên bản Linux và tôi tự hỏi lý do đằng sau nó là gì.
terdon

Có vẻ được thực hiện theo cách đó trong thượng nguồn debian .
Elliott Frisch

@ElliottFrisch vâng, tôi nghĩ rằng nó không phải và nhìn lên và thấy nó là thời gian để chỉnh sửa nhận xét của tôi. Tuy nhiên, đó không phải là trường hợp trên hệ thống SuSe mà tôi có quyền truy cập (mặc dù là trên hệ thống CentOS) và không phải là trường hợp trên các hệ thống khác nhau (RHs, Fedoras, Ubuntus cũ) theo như tôi nhớ. Vì vậy, tôi tự hỏi tại sao.
terdon

Câu trả lời:


15

Đây là một quyết định ngược dòng đến từ Debian. Lý do cho nó được giải thích trong bài viết wiki rất hay này , trong đó sau đây là một đoạn trích. Tóm tắt điều hành là "để đảm bảo rằng các thông tin đăng nhập GUI và không GUI hoạt động theo cùng một cách":

Hãy lấy xdm làm ví dụ. pierre trở lại sau kỳ nghỉ một ngày và phát hiện ra rằng quản trị viên hệ thống của mình đã cài đặt xdm trên hệ thống Debian. Anh ta đăng nhập tốt, và xdm đọc tệp .xsession của anh ta và chạy fluxbox. Mọi thứ dường như đều ổn cho đến khi anh ta nhận được thông báo lỗi ở địa phương sai! Vì anh ta ghi đè biến LANG trong .bash_profile của mình và vì xdm không bao giờ đọc .bash_profile, nên biến LANG của anh ta được đặt thành en_US thay vì fr_CA.

Bây giờ, giải pháp ngây thơ cho vấn đề này là thay vì khởi chạy "xterm", anh ta có thể định cấu hình trình quản lý cửa sổ của mình để khởi chạy "xterm -ls". Cờ này cho xterm biết rằng thay vì khởi chạy shell thông thường, nó sẽ khởi chạy shell đăng nhập. Theo thiết lập này, xterm sinh ra / bin / bash nhưng nó đặt "- / bin / bash" (hoặc có thể là "-bash") trong vectơ đối số, vì vậy bash hoạt động như một vỏ đăng nhập. Điều này có nghĩa là mỗi khi anh ta mở một xterm mới, nó sẽ đọc / etc / profile và .bash_profile (hành vi bash tích hợp), sau đó .bashrc (vì .bash_profile nói để làm điều đó). Điều này có vẻ hoạt động tốt lúc đầu - các tệp chấm của anh ấy không nặng, vì vậy anh ấy thậm chí không nhận thấy sự chậm trễ - nhưng có một vấn đề tinh tế hơn. Anh ta cũng khởi chạy một trình duyệt web trực tiếp từ menu fluxbox của mình, và trình duyệt web kế thừa biến LANG từ fluxbox, hiện được đặt thành ngôn ngữ sai. Vì vậy, trong khi các xterms của anh ta có thể ổn, và bất cứ điều gì được khởi chạy từ các xterms của anh ta đều ổn, trình duyệt web của anh ta vẫn đưa cho anh ta các trang ở địa phương sai.

Vì vậy, giải pháp tốt nhất cho vấn đề này là gì? Thực sự không phải là một cái phổ quát. Cách tiếp cận tốt hơn là sửa đổi tệp .xsession để trông giống như thế này:

[ -r /etc/profile ] && source /etc/profile
[ -r ~/.bash_profile ] && source ~/.bash_profile
xmodmap -e 'keysym Super_R = Multi_key'
xterm &
exec fluxbox

Điều này khiến trình bao diễn giải tập lệnh .xsession đọc trong / etc / profile và .bash_profile nếu chúng tồn tại và có thể đọc được, trước khi chạy xmodmap hoặc xterm hoặc "thực thi" trình quản lý cửa sổ. Tuy nhiên, có một nhược điểm tiềm năng đối với phương pháp này: dưới xdm, trình bao đọc .xsession chạy mà không có thiết bị đầu cuối kiểm soát. Nếu / etc / profile hoặc .bash_profile sử dụng bất kỳ lệnh nào giả sử sự hiện diện của thiết bị đầu cuối (chẳng hạn như "fortune" hoặc "stty"), các lệnh đó có thể thất bại. Đây là lý do chính tại sao xdm không đọc các tệp đó theo mặc định. Nếu bạn sẽ sử dụng phương pháp này, bạn phải đảm bảo rằng tất cả các lệnh trong "tệp chấm" của bạn đều an toàn để chạy khi không có thiết bị đầu cuối.


Tôi vẫn nghĩ rằng đó không phải là một ý tưởng tuyệt vời. Người lý tưởng sẽ đảm bảo rằng trình quản lý hiển thị sẽ cung cấp một hồ sơ toàn cầu (kiểm tra) và shell người dùng .profile. Bây giờ tôi biết tại sao tôi có các đường dẫn trùng lặp trong một số biến ...
Rmano

2

Đây là hành vi tiêu chuẩn của Ubuntu, ~/.bashrclà tệp khởi động trình bao tương tác cấp độ người dùng. Khi bạn mở một thiết bị đầu cuối về cơ bản, bạn bắt đầu một lớp vỏ tương tác không đăng nhập, đọc ~/.bashrcvà nội dung ~/.bashrcđược lấy nguồn và xuất vào môi trường shell hiện tại của bạn. Nó giúp người ta có được tất cả các biếnhàm shell do người dùng xác định trong shell hiện tại. Ngoài ra, bạn có thể tìm thấy những dòng như thế này

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

để có được bí danh người dùng xác định trong môi trường shell hiện tại.

Điều này cũng quan trọng để cung cấp trải nghiệm người dùng tốt. Ví dụ người ta có thể lưu trữ trong chứng ủy quyền .bashrc, trừ khi nó được nguồn gốc không ai trong số các ứng dụng thiết bị đầu cuối ( tức là , ping, wget, curl, lynxvv) sẽ hoạt động tốt. Hoặc bạn phải cung cấp thông tin đăng nhập proxy mỗi khi bạn mở thiết bị đầu cuối.

Bên cạnh mặc định của Ubuntu .bashrcchứa nhiều bí danh thân thiện với người dùng (cho lsgrepđể in đầu ra được tô màu), nhiều định nghĩa mới cho các biến shell khác nhau làm tăng trải nghiệm người dùng.

Nhưng trong trường hợp đăng nhập ssh của bạn , hoặc đăng nhập trong bảng điều khiển ảo , về cơ bản bạn sẽ có được một vỏ đăng nhập tương tác. Có tập tin khởi tạo shell là ~/.profile. Do đó trừ khi bạn nguồn ~/.bashrcbạn bỏ lỡ tất cả các cài đặt hữu ích trong của bạn .bashrc. Đó là lý do tại sao ~/.profilenguồn mặc định của Ubuntu~/.bashrc

Trường hợp cần tránh

  • bạn không bao giờ nên lấy ~/.profilemẫu bên trong ~/.bashrccùng một lúc khi ~/.bashrccó nguồn gốc từ ~/.profile. Nó sẽ tạo ra một vòng lặp vô hạn của tình huống và kết quả là dấu nhắc thiết bị đầu cuối của bạn sẽ bị treo trừ khi bạn nhấn Ctrl+ C. Trong tình huống như vậy nếu bạn đặt một dòng trong~/.bashrc
đặt -x

Sau đó, bạn có thể thấy rằng bộ mô tả tập tin đang dừng khi bạn mở một thiết bị đầu cuối.


Cảm ơn, đây là tất cả thông tin đúng và hữu ích. Nó chỉ không giải quyết câu hỏi của tôi. Tôi quen thuộc với sự khác biệt giữa shell đăng nhập và không đăng nhập. Câu hỏi của tôi là tại sao, trên các hệ thống Ubuntu, là .profiletìm nguồn cung ứng .bashrc? SuSe Enterprise 10 không làm điều đó, bất kỳ phiên bản Fedora nào tôi đã sử dụng nhưng đó là những năm trước đây, tôi có thể sai. CentOS 5.8 không đủ kỳ lạ. Dù sao, bạn thấy quan điểm của tôi? Đây là một sự lựa chọn thiết kế và tôi tự hỏi tại sao nó được thực hiện.
terdon

Tôi đã không sử dụng nghiêm ngặt các bản phân phối Linux khác mà bạn đặt tên. bạn có thể cho tôi biết cách họ xử lý các tình huống như các lệnh bí danh trong phiên ssh được xác định trong .bashrchoặc trong .bash_aliases. Ví dụ, tôi có một bí danh lsnhư ls --color=autotrong tôi .bashrcvà tôi .bashrccó nguồn gốc từ tôi .profile. Ở đây tôi có thể sử dụng bí danh ngay cả từ ssh. Hoặc tôi có thể sử dụng proxy trong phiên ssh. Nếu tôi không lấy nguồn .bashrctừ .profiletôi, tôi sẽ mất các tính năng đó. Tôi nghĩ đó là tất cả về trải nghiệm người dùng tốt hơn.
souravc

Họ không, những bí danh đó sẽ không hoạt động. Và vâng, tìm nguồn cung ứng .bashrcsửa chữa điều đó. Nhưng nó cũng gây ra vấn đề, tôi nhớ lần đầu tiên tôi sử dụng một hệ thống mà có hành vi này tôi vẫn tiếp tục nhận được những tin nhắn lạ khi sshing để nó gây ra tôi đã sử dụng xset b offtrong tôi .bashrcmà sử dụng để vô hiệu hóa chuông terminal nhưng chỉ trong một hệ thống X nên nó đã đưa ra thông báo lỗi. Mất nhiều thời gian để tìm hiểu những gì đang diễn ra vì tôi không nghĩ rằng nó .bashrcsẽ được đọc khi chạy shell đăng nhập. Tôi chỉ tự hỏi nếu có một tuyên bố "chính thức" về điều này.
terdon

Tôi đồng ý với bạn. Tôi cũng phải đối mặt với một số rắc rối trước đó . Nhưng nó chủ yếu là hữu ích và thân thiện với người dùng, nếu bạn ghi nhớ và tránh một vài trường hợp đặc biệt. Phải không :)
souravc 11/03/2016

Vâng, có những lý do hợp lệ cho việc này. Tôi chỉ tò mò liệu Canonical có từng đưa ra lý do của họ để giữ quyết định ngược dòng này không.
terdon
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.