Two useful command-line tools are 'man', as in "man progname" which provides an, sometimes quite detailed, guide to using the the program and 'apropos' as in "apropos compilers" which scans the title line of all manpages and shows you the matches, i.e. a list of programs that may do what you want if you don't know what to use to do a job. However, beware that it only works well if 'updatedb' has been run relatively recently.
I have a cronjob set up on my Fedora systems to run updatedb every night, but I run it manually with a "sudo updatedb" command on my RPi before running 'apropos' or 'locate' (the latter is a fast file finder).
There's a comprehensive online guide to Debian Linux here:
formatting link
and since Raspbian is pretty much just the standard Debian Linux distro recompiled to run on the RaspberryPi, almost everything in it is also true for Raspbian Linux.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
FYI the convention is that locally developed programs should go in /usr/ local/bin if they are for anybody to run and /usr/local/sbin if they should only be run by root. because these directories are defined in the $PATH environment variable by default.
Since programs that are part of the RaspberryPi distribution will be put in /bin, /usr/bin, /sbin or /usr/bin this keeps your programs from being stomped on by system updates while still making them available to all relevant users.
Similarly, global configuration files for your own programs should go in / usr/local/etc and manpages, if you write them, in the /usr/local/man directory structure.
BTW, did you spot a major difference between Linux and Windows when a program is searching for files supplied as command line parameters?
For a program running on Linux the base directory for finding a file is your current working directory but on Windows it is the directory holding the executable.
As a consequence its a good practise to write programs that have a configuration file to look for it first in '.' (the current working directory), then in /usr/local/etc and finally in /etc because this lets you test the program in your development user with a test configuration file in the same directory and then, in production, put its default configuration file in /usr/local/etc so users with special needs can keep their configuration in their own directories.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
My RPi has been known to fail to find stuff, particularly with 'locate', without manually running updatedb, but that could well be because its not doing a lot at present, and simply hasn't been on long enough for atd to have kicked in and run the stuff that crond missed while the RPi was powered off.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
No, the packages contain cron jobs that keep things up to date.
The locate database is normally updated overnight. If you want to find recently created things, ?find? is the right command, although if you?re frequently creating things without knowing where they are, maybe it?s time to think about why that is and whether it?s sensible.
Other platforms (macOS, Windows) manage essentially instant updates of whole-system indexes, I don?t know why Linux is still stuck with batch updates like it?s 1970 or something.
On Wed, 22 Nov 2017 10:59:35 +0100, "R.Wieser" declaimed the following:
In all my uses of apt-get, I've either been upgrading packages
apt update apt upgrade
or completely installing one (meaning the package manager not only downloads it, but unpacks it and puts the components into the standard locations, and maybe even finds missing dependencies and installs them too)
apt update apt-get install packagename
(though I'll admit for installing packages I usually use the graphical tool for the distribution -- which I've always found under the system or settings entry in the desktop environment -- mainly because its a bigger pain to search the package list with wildcards to find a candidate, vs just scrolling down a long list)
Practically every tutorial I've encountered for embedded Linux boards with a discussion of installing packages tends to include that command somewhere. "Exploring Raspberry Pi" has a two page spread on APT, though doesn't explain why one would use it. I'll admit that most of my library is BeagleBone Black oriented -- but both devices have ARM-based processors running some version of Debian (RPi is more customized, considering they called it "raspbian" and their LXDE desktop "Pixel").
It is often the first thing done after installing the OS -- in order to update packages that have changed since the distribution image was made. (Unlike M$, which under Win10 shoves updates at you whether you want them or not tying up the network, Linux requires the administrator to periodically perform that function).
formatting link
has it as the last part of the section -- on upgrading software
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
Fedora uses both crond and atd: crond runs jobs as they come due but misses jobs if it wasn't running at that time. atd runs all the jobs that crond missed and runs them as some short random time after Lunux was booted or comes out of suspension/hibernation.
I though all Linux distros used this same duality and I was right, but some distros don't install atd by default. Fedora does and Raspbian doesn't.
The 'at' package, which includes at and atd, is now installed on my RPi, so updatedb will now get run automatically a bit more often. I'm no longer surprised that updatedb has never been automatically run here because all daily jobs are run at 06:30 and AFAICR my RPi has never been running at that time.
Related point: I thought 'locate' was installed by default for Raspbian, but it ain't. It turns out its in the 'locate' package and I'd installed that a long time ago.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
If your computer isn't on 24x7, you should install anacron which will take care of all /etc/cron.daily, .weekly and .monthly jobs (see /etc/anacrontab). /etc/crontab, /etc/cron.d and individual crontabs are still run by cron.
Yes, I suspect Julian Smart had used Microsoft's MFC framework for C++ before he started writing wxWindows (as it was then called) for cross-platform development. There's some similarity in naming, and some of the same techniques are used (where applicable, when there isn't anything obviously better) ... but wx has it's own 'style' in which the underlying platform details are more abstracted-away than in (say) MFC.
Yes, compatibility is helpful ... as long as you know where it stops!
[I remember those ... too bad OWL2 wasn't more widely adopted, I always thought.]
A window is a GUI abstraction that carries a lot of baggage (especially in Windows!) so a class that manages one is going to be big.
I don't recall what OWL, in particular, did to split that up (I still have the manuals, somewhere ... and that was back in the day when manuals were well-written and thorough).
A fair question. When you're new to this it feels a bit like ordering food at a restaurant where they won't show you the menu.
I believe we've ascertained that you're using Raspbian (Debian Linux for the Pi) which uses the LXDE desktop, which is built with GTK+ ... so why not take a look at GTK+?
There's a tutorial for GTK+ 3 here:
formatting link
why not take a look and see whether it's the sort of thing that you think you're likely to like?
I've noticed some new systems, eg Ubuntu 16's bash, go a step further and add $HOME/bin (very traditional) and $HOME/.local/bin to the PATH. What's with the second one? I've (on multi-user systems) used a scheme like:
PATH=$HOME/bin:$SYSTEM_PATH:$HOME/usr/bin
Where the things in $HOME/usr/bin are stuff I've compiled myself, but I'd prefer a system one if it comes along; and the things in $HOME/bin are programs for which I always want mine to "win". Is the .local/bin thing something similar?
You were directing that at someone else, but I don't think that ever sunk in with me, except for library path stuff. This is a symptom of my infrequent use of Windows.
I'm not in favor of things searching for configuration in the *current* directory by default. That way leads to surprises. My feel for a "unix like" search path for configuration falls under two modes of thought. If a program will use a single configuration file (but allowed for that configuration file to include other files), then it should be
The *last* conf file specified on the command line 2. If no command line file, then the conf file specied by environment variable 3. If no environment variable, then the conf file in $HOME/.progrc 4. If no $HOME/.progrc, then go to a compiled-in default path for a directory/progrc 5. Lastly looking in /etc/progrc
This sort of behavior is best suited for system programs, which might have a dedicated user account.
If a program will use multiple configuration files, each one modifying the configuration state (like CSS files), then:
All of the conf files specified on the command line * with the option of the command line specifying these files are exclusive of other files 2. If non-exclusive, then the conf file specified by environment variable 3. If no environment variable, then the conf file found in a compiled-in default path for a directory/progrc, with /etc/progrc last 4. The user's personal $HOME/.progrc 5. *Additional* configuration commands specified by environment variable (as in commands in variable, rather than filenames) 6. *Additional* configuration commands specified on the command line 7. Maybe now look for a current directory ./.progrc
Look at how ssh or vim handles configuration for an example of this. To get the local directory stuff to work, somewhere else has to enable the "exrc" option in vim (so-named for compatibility). Whereas ssh will never use the current directory config without it being explicitly included, for security reasons.
For testing, always use an exclusive config file on the command line. That's how you can, as a regular user, run your own configuration of the system web daemon or your own high-port sshd.
I've never seen that. I can't imagine why it would be needed either, let alone why it should be hidden except from 'ls -a'. However, I can see the point of making programs search first for ~/.config or .config rather than for config or ./config, simply because it doesn't clutter a directory with configuration files. I wouldn't do that, though, because I like to see and often need to modify a user-specific configuration file.
I do that - using ~/bin, I mean, but usually just for scripts, but I've never needed (yet) to have one collection of programs that pre-empt the default pathlist and another set that are overridden by it.
Is the .local/bin thing something similar?
As I say, I've never seen it before, but then Ubuntu do go off along their own, rather different, track sometimes. I like what I've seen of Mint/Cinnamon but have never liked the Unify, Gnome 3 and KDE desktops.
I've used the Redhat distro since RH 6.4 and now use Fedora/XFCE on my X-64 systems. If I was going to move on it would be to Debian Stable rather than any of the forks, but since I think apt isn't a patch on dnf for general ease of use, especially now Fedora has the ability to move to the next distro version without a clean install or burning a DVD, - IMO the package manager is a good enough reason to stay with Fedora.
Back in the day, when I was using Win95 alongside Microware's OS/9 and Linux I got my nose rubbed in that.
Actually, there's an obvious clue - the fact that the configuration file (s) for Windows apps are almost always in the same directory as the executable that uses them while UNIX/Linux/OS/9 put them in /etc
This points directly to Windows being designed for a single user because it puts the kybosh on different users being able to set different configuration preferences. OTOH UNIX and its clones have always been multi-user systems and so have always required a more flexible, per-user oriented way of handling application configuration.
Thats why I suggested the search path should be ".:/usr/local/etc:/etc" Because the default can be put in /etc or /usr/local/etc - sysadmin's choice (put it in /etc if the program is in /bin or /usr/bin and in /usr/ local/etc if the program is in /usr/local/bin) while making a user- specific configuration is as simple as copying the default configuration to '.' and editing it there.
Actually, I also go one step further by almost always implementing a '- c=/path/to/config.file' command line option if the program has a configuration file. That works well regardless of whether the program is written in C,Java,Python,...
Yes, that also looks like a good solution, though a little harder to implement, since mine is very simple:
fn = "" IF -c=file option exists fn = file ELSE FOR dir IN ".:/usr/local/:/etc" IF dir/file EXISTS fn = dir/file
IF file == "" SET-ERROR No file specified STOP ELSE OPEN fn ON-SUCCESS parse configuration RUN application ELSE SET-ERROR File not found
I've usually seen this done either by making the program read all the files in a directory and giving them a numeric prefix if their order is important or by referencing a single file that has INCLUDE or INCLUDE_DIR statements, but so fat I haven'r needed anthing so complex.
Actually, there was one case where the very complex configuration included a data dictionary (the project requirement said that we had to be able to accept arbitrary changes in the input data format that we were parsing, converting to a common data structure and and storing in a data warehouse), but here I cheated by making the configuration parser into a separate program that validated stored the configuration in a few tables in the data warehouse. The various programs in the data handling chain read their configuration from the database.
Indeed - hence my use of the -c-config command-line option.
It looks like we're in total agreement on this one!
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
I'm actually supposing about OWL, because Borland Canada's back office was very crumbly and never did deliver me the version of C++ that had OWL. The split was that View supplied the base class for everything that would appear on the screen, while Group instances handled all the messaging up and down the parent-child tree. Effectively all parents were Group instances, and all View instances were children. I don't remember the details of my confusion, but I do recall having some trouble with the different roles my objects wound up having under Windows OS.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.