[arch-general] package contents on fresh Arch install, like python etc...
Dear Archers, A day back, i made a fresh install of Arch on my desktop. It is completely fresh as like it doesnt even have an account other than root. My doubt is, wont basic tools like python come in Arch install? or do we have to install by ourselves? also can anyone give me a brief approximate list of packages that will come pre-installed in Arch, other than gnu tools? Thanks in advance yours fellow newbie Archer Ramkumar
A day back, i made a fresh install of Arch on my desktop. It is completely fresh as like it doesnt even have an account other than root. My doubt is, wont basic tools like python come in Arch install? or do we have to install by ourselves? You are the administrator. You are choosing what you want to be installed. The base group contains only the basic tools and their dependencies.
also can anyone give me a brief approximate list of packages that will come pre-installed in Arch, other than gnu tools? pacman -Sg base
On June 21, 2019 12:05:23 AM EDT, Ram Kumar via arch-general <arch-general@archlinux.org> wrote:
Dear Archers, A day back, i made a fresh install of Arch on my desktop. It is completely fresh as like it doesnt even have an account other than root. My doubt is, wont basic tools like python come in Arch install? or do we have to install by ourselves?
also can anyone give me a brief approximate list of packages that will come pre-installed in Arch, other than gnu tools?
Thanks in advance yours fellow newbie Archer Ramkumar
That's not really how it works. Arch does not come with programs preinstalled, because when you follow the Installation Guide and `pacstrap` a new system, you interactively choose which programs from the base group are desired. What will be installed is: - A kernel, because you need it to boot. - Pacman, because it is used for installing and removing things. - Standard POSIX tools (*not* gnu tools) like the core utilities, grep, awk, sed, tar, find, sh and so on. Note that most are the GNU versions by default, but it is possible to swap them out, e.g. use busybox. - Select tools that are used by people for basic setup, like filesystem support tools or networking tools (wpa_supplicant, netctl). Python, and anything else you want on an application level, should be generally assumed to not exist unless you install it manually or unless it is basic scripting tools that are advertised by POSIX (in which case you can usually use them on any Linux distro without checking whether they are installed). -- Eli Schwartz Bug Wrangler and Trusted User
Wow.. thank u guys for explanation and for command "pacman -Sg base" .. now i understood.. On Fri, 21 Jun 2019, 10:14 am Eli Schwartz, <eschwartz@archlinux.org> wrote:
On June 21, 2019 12:05:23 AM EDT, Ram Kumar via arch-general < arch-general@archlinux.org> wrote:
Dear Archers, A day back, i made a fresh install of Arch on my desktop. It is completely fresh as like it doesnt even have an account other than root. My doubt is, wont basic tools like python come in Arch install? or do we have to install by ourselves?
also can anyone give me a brief approximate list of packages that will come pre-installed in Arch, other than gnu tools?
Thanks in advance yours fellow newbie Archer Ramkumar
That's not really how it works. Arch does not come with programs preinstalled, because when you follow the Installation Guide and `pacstrap` a new system, you interactively choose which programs from the base group are desired.
What will be installed is: - A kernel, because you need it to boot. - Pacman, because it is used for installing and removing things. - Standard POSIX tools (*not* gnu tools) like the core utilities, grep, awk, sed, tar, find, sh and so on. Note that most are the GNU versions by default, but it is possible to swap them out, e.g. use busybox. - Select tools that are used by people for basic setup, like filesystem support tools or networking tools (wpa_supplicant, netctl).
Python, and anything else you want on an application level, should be generally assumed to not exist unless you install it manually or unless it is basic scripting tools that are advertised by POSIX (in which case you can usually use them on any Linux distro without checking whether they are installed).
-- Eli Schwartz Bug Wrangler and Trusted User
On Fri, 21 Jun 2019, mpan wrote:
Date: Fri, 21 Jun 2019 00:38:12 From: mpan <archml-y1vf3axu@mpan.pl> Reply-To: General Discussion about Arch Linux <arch-general@archlinux.org> To: arch-general@archlinux.org Subject: Re: [arch-general] package contents on fresh Arch install, like python etc...
A day back, i made a fresh install of Arch on my desktop. It is completely fresh as like it doesnt even have an account other than root. My doubt is, wont basic tools like python come in Arch install? or do we have to install by ourselves? You are the administrator. You are choosing what you want to be installed. The base group contains only the basic tools and their dependencies.
also can anyone give me a brief approximate list of packages that will come pre-installed in Arch, other than gnu tools? pacman -Sg base
Also, man which If you get a chance the linux cookbook will be informative reading given your new position. --
On 6/21/19 12:13 PM, Jude DaShiell wrote:
Also, man which If you get a chance the linux cookbook will be informative reading given your new position.
Please do *not* use /usr/bin/which, especially not if you write scripts. It is non-POSIX, not portable between different different systems if you write scripts, and even on an interactive console where you know you personally have the "which" package installed, the results are more confusing and less useful than using the native shell introspection. use `command -v` to find where a command exists, or, in bash, `type -a` if you want to see all possible options. For more details, see: https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use... Especially note the "Status today" paragraphs, and if you stubbornly wish to continue using "which" despite its well-known pitfalls, then carefully avoid any systems where "which" is implemented as a csh script (like many commercial Unix systems today). ... Use the "conflict" command if you're afraid you may have multiple versions of an externally available executable file in your $PATH and you want to check where they are and what you're actually using. Since the common use case of "which" is when you actually want to know whether you're using the wrong version of something, the ideal interactive debugging tool is "type -a"... but the "conflict" command can do one better -- limited to executables and not shell builtins, aliases, or functions -- and list *all* conflicting command binaries. -- Eli Schwartz Bug Wrangler and Trusted User
On 21/06/2019 19:45, Eli Schwartz via arch-general wrote:
On 6/21/19 12:13 PM, Jude DaShiell wrote:
Also, man which If you get a chance the linux cookbook will be informative reading given your new position. Please do *not* use /usr/bin/which, especially not if you write scripts. It is non-POSIX, not portable between different different systems if you write scripts, and even on an interactive console where you know you personally have the "which" package installed, the results are more confusing and less useful than using the native shell introspection.
use `command -v` to find where a command exists, or, in bash, `type -a` if you want to see all possible options.
For more details, see: https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use... Especially note the "Status today" paragraphs, and if you stubbornly wish to continue using "which" despite its well-known pitfalls, then carefully avoid any systems where "which" is implemented as a csh script (like many commercial Unix systems today).
...
Use the "conflict" command if you're afraid you may have multiple versions of an externally available executable file in your $PATH and you want to check where they are and what you're actually using.
Since the common use case of "which" is when you actually want to know whether you're using the wrong version of something, the ideal interactive debugging tool is "type -a"... but the "conflict" command can do one better -- limited to executables and not shell builtins, aliases, or functions -- and list *all* conflicting command binaries.
Should you always create POSIX-compatible scripts though? All these non-POSIX tools were created to ease your job, and you blow them away as non-POSIX? If you're creating a single-purpose local script, I think it's fair to make it a bash script and use tools which you have available on your install, instead of limiting yourself to frankly ridiculous workarounds to the shortcomings of POSIX. Just because a tool can do anything doesn't mean it can do everything well, or that you have enough cognitive capacity at 3 am to write your stupid POSIX-compatible shell scripts. P.S. which is an absolutely terrible command though, modern POSIX alternatives are much better for this specific use case. -- Regards, Juha Kankare
participants (5)
-
Eli Schwartz
-
Jude DaShiell
-
Juha Kankare
-
mpan
-
Ram Kumar