Tag Info

Hot answers tagged

301

System calls aren't handled like regular function calls. It takes special code to make the transition from user space to kernel space, basically a bit of inline assembly code injected into your program at the call site. The kernel side code that "catches" the system call is also low-level stuff you probably don't need to understand deeply, at least at ...


55

This probably doesn't answer your question directly, but I've found strace to be really cool when trying to understand the underlying system calls, in action, that are made for even the simplest shell commands. e.g. strace -o trace.txt mkdir mynewdir The system calls for the command mkdir mynewdir will be dumped to trace.txt for your viewing pleasure.


29

A good place to read the Linux kernel source is the Linux cross-reference (LXR). Searches return typed matches (functions prototypes, variable declarations, etc.) in addition to free text search results, so it's handier than a mere grep (and faster too). LXR doesn't expand preprocessor definitions. System calls have their name mangled by the preprocessor ...


26

It's usually plain C. The commands ls and pwd come from the GNU Coreutils package in (most?) Linux distributions (and maybe some other systems). You can find the code on their homepage. For coreutils specifically, you build them with the usual steps: after unpacking the source, issue: ./configure --prefix=/some/path # type ./configure ...


26

All software are programs, which are also called source packages. So all source packages need to be built first, to run on your system. The binary packages are one that are already build from source by someone with general features and parameters provided in the software so that a large number of users can install and use it. Binary packages are easy to ...


22

A source file contains the original code as written by the developer in whatever language he/she chooses (C, C++, Python etc),and is generic. It isn't specific to any distro and in many cases to any operating system. A package (RPM or DEB for example) is the binary executable (or interpreted script etc) pre-prepared for your particular distro. The task of ...


17

In tcsh, $_ at the beginning of the script will contain the location if the file was sourced and $0 contains it if it was run. #!/bin/tcsh set sourced=($_) if ("$sourced" != "") then echo "sourced $sourced[2]" endif if ("$0" != "tcsh") then echo "run $0" endif In Bash: #!/bin/bash called=$_ [[ $called != $0 ]] && echo "Script is being ...


17

The uname utility gets its information from the uname() system call. It populates a struct like this (see man 2 uname): struct utsname { char sysname[]; /* Operating system name (e.g., "Linux") */ char nodename[]; /* Name within "some implementation-defined network" */ char ...


16

I think that you could use $BASH_SOURCE variable. It returns path that was executed: pbm@tauri ~ $ /home/pbm/a.sh /home/pbm/a.sh pbm@tauri ~ $ ./a.sh ./a.sh pbm@tauri ~ $ source /home/pbm/a.sh /home/pbm/a.sh pbm@tauri ~ $ source ./a.sh ./a.sh So in next step we should check if path is relative or not. If it's not relative everything is ok. If it is we ...


16

Welcome to unix.stackexchange.com! There's no easy answer to your question, and far better people than me have written entire books on the subject of the Linux kernel and operating systems in general. About the scope of the project: writing an operating system is not a simple task! Even a purposefully minimal OS like Minix is a pretty complex thing! To ...


15

Firstly, according to the File System Hierarchy Standards, the location of this installed package should be /opt if it is a binary install and /usr/local if it's a from source install. A binary package is going to be easy: sudo tar --directory=/opt -xv f <file>.tar.[bz2|gz] add the directory to your path: export PATH=$PATH:/opt/[package_name]/bin ...


13

Normally, the project will have a website with instructions for how to build and install it. Google for that first. For the most part you will do either: Download a tarball (tar.gz or tar.bz2 file), which is a release of a specific version of the source code Extract the tarball with a command like tar zxvf myapp.tar.gz for a gzipped tarball or tar jxvf ...


13

System calls are usually wrapped in the SYSCALL_DEFINEx() macro, which is why a simple grep doesn't find them: fs/namei.c:SYSCALL_DEFINE2(mkdir, const char __user *, pathname, int, mode) The final function name after the macro is expanded ends up being sys_mkdir. The SYSCALL_DEFINEx() macro adds boilerplate things like tracing code that each syscall ...


12

Apart from the other answers, I would like to add something: If you decide to compile a program by yourself, you need to think that compiling is not something you do only once. You will probably need to subscribe to the development mailing list of the applications you decided to compile and stay up to date with the new versions and, especially, the security ...


11

Note: the .h file doesn't define the function. It's declared in that .h file and defined (implemented) elsewhere. This allows the compiler to include information about the function's signature (prototype) to allow type checking of arguments and match the return types to any calling contexts in your code. In general .h (header) files in C are used to ...


11

Distribution kernel-header packages contain, as their name implies, only kernel header files (plus the necessary plumbing) that are required to build software like kernel modules. You shouldn't expect to find binary files at all in a kernel source directory, except for build output. (If you configure and build a kernel yourself, the kernel source directory ...


10

Building from source provides the following options which are not available when using a version from a binary package manager. Compiling from source allows you to: use processor-specific optimizations use the very latest version learn how compilation & linking work (suggestion from @mattdm) fix bugs, development work set compile-time options (e.g. ...


10

The -dev packages usually contain header-files, examples, documentation and such, which are not needed to just running the program (or use a library as a dependency). They are left out to save space. ArchLinux usually just ships these files with the package itself. This costs a bit more disk space for the installation but reduces the number packages you ...


10

Debian Installer is actually a bunch of different packages, in several repositories. The Debian Wiki has a page on how to get the Debian Installer source: Make sure mr is installed, and: svn co svn://anonscm.debian.org/svn/d-i/trunk debian-installer cd debian-installer scripts/git-setup mr -p checkout Beware it'll take a while, as its ~480MB. The ...


9

Unpack the files and then, in the directory that was created, look for a README or INSTALL file which will tell you what you need to know in order to install a package (e.g. dependencies, configuration options, commands to run etc...). Usually it boils down to ./configure, make then make install.


9

As mentioned on LWN, the easiest is: git describe --contains f3a1ef9cee4812e2d08c855eb373f0d83433e34c If you don't want a local clone, gitweb's "plain" formatted commit contains the same info in the X-Git-Tag header. Unfortunately kernel.org switched over to cgit which apparently does not disclose this information. Previously it was possible to find it ...


8

Short answer: not possible. The difficulty of getting the exact dependencies from a source distribution is the reason why package management is so popular on Linux (okay, one of several reasons). In fact, if you just need to get it done and don't care so much how, the most reliable way to get the dependencies will probably be to grab a distro package (gentoo ...


8

In general, on a RPM-based distribution like Fedora, you can find the name of the package which provides a given command with rpm -qf /path/to/command. Like this: $ rpm -qf $( which uptime ) procps-3.2.8-18.20110302git.fc16.x86_64 You can then download the source RPM with yumdownloader --source procps. (yumdownloader comes from the yum-utils package, if ...


8

apt-file can be used for queries like this. If you know that say is an executable, you can search for /usr/bin/say. You could also try /bin/say. faheem@orwell:~$ apt-file search /usr/bin/say gnustep-gui-runtime: /usr/bin/say libgnustep-gui0.20-dbg: /usr/lib/debug/usr/bin/say libgnustep-gui0.22-dbg: /usr/lib/debug/usr/bin/say saytime: /usr/bin/saytime You ...


8

You have to use grep -r CONFIG_SND_SOC_MXS_SGTL5000. Each of these config options just represents a #define macro. Many of them don't belong to a single file but instead are checked in multiple source files. CONFIG_64BIT for example appears in around 1k source code files.


7

I'm not aware of a complete "build the system from source" tool for Debian, but it does support this in a round-about way via apt-src, which will download and build a package, then install the resulting build.


7

Uptime is part of the 'procps' package, the upstream source is at http://procps.sourceforge.net/ (Not a fedora user, so not sure where to find their .src.rpm). To answer the question you didn't ask, however; take a look in /proc/uptime The first number is seconds since boot. You should be able to turn that into something usable fairly easily :)


7

grep works on pure text and does not know anything about the underlying syntax of your C program. Therefore, in order not search inside comments you have several options: Strip C-comments before the search, you can do this using gcc -fpreprocessed -dD -E yourfile.c For details, please see ...


6

There are a few distros which support both binary and compiled packages--in theory, Gentoo supports this, but I don't think there are too many binary packages. Arch also supports building from source in addition to binary packages via the Arch Build System (ABS), though I don't have any experience with it.


6

For thoroughness and the sake of searchers, here is what these do... It is a community wiki, so feel free to add other shell's equivalents (obviously, $BASH_SOURCE will be different). test.sh: #! /bin/sh called=$_ echo $called echo $_ echo $0 echo $BASH_SOURCE test2.sh: #! /bin/sh source ./test.sh Bash: $./test2.sh ./test2.sh ./test2.sh ./test2.sh ...



Only top voted, non community-wiki answers of a minimum length are eligible