What is your favorite shell?

No, archiving is considered important, not only by archives that have it as their proper task, but for shorter terms (for example 30 years) also for other state agencies and private companies. It is a very important, but neglected issue.
 
Agreed. Actually my PhD is on digital preservation of software (games), where archiving is a close relative to the problem.

The main thing is that there is "currently" no money in it and too many people these days are in for a quick buck. They don't care about the future or their users in the future.

There is no easy fix. For example GNU software that drags in a number of unmaintainable dependencies still attribute to this problem even though it is "open-source". Not only does something need to be open-source but also architected in a responsible manner.

Quite off topic. ;)
 
There is no easy fix. For example GNU software that drags in a number of unmaintainable dependencies still attribute to this problem even though it is "open-source".
A preservation of assembler code and small areas of code for base operating systems are necessary for a stable function.


Agreed. Actually my PhD is on digital preservation of software (games), where archiving is a close relative to the problem.

The main thing is that there is "currently" no money in it and too many people these days are in for a quick buck. They don't care about the future or their users in the future.

There is no easy fix. For example GNU software that drags in a number of unmaintainable dependencies still attribute to this problem even though it is "open-source". Not only does something need to be open-source but also architected in a responsible manner.

Quite off topic. ;)

Quite Off Topic

Money rules computer sciences.

The problem is that social phenomena and human lives are made to be in relation with digital systems. Education tends to be digital in Europe * except sweden,...

Writing among our society is most important - and likely more important than archiving knowledge.
When did you write a letter?
 
... it will be there for 30 years: for normal use I preffer ufs. I use magnetic disks, not flash rom, for archiving, but the firmware of the disc is sure flash rom and the whole data goes with it. And are modern magnetic disks or tapes with so dense data reliable?
Last I heard, the lifetime expectation of SSDs is spec'ed as "at least 10 years", obviously ignoring flash wear out due to too many writes. The real-world life time of disks in large quantities is about 5-7 years; after that older disks are no longer economically viable (too little storage capacity per physical space and power consumption, often quoted as GB/l and GB/W), and it becomes cheaper to copy the data to newer disks.

Matter-of-fact, the lifetime of physical storage devices it not highly relevant to the lifetime of the data itself. Information is always stored redundantly at industrial scale, so the failure of individual devices is merely an inconvenience and a cost. Data is then copied regularly to newer devices, either because the old device failed, or because it becomes economically cheaper to use newer (higher capacity) devices.

There has been research on storage devices that can store data for very long periods, without recopying. There is some work on etching information into thin nickel foils. I actually have a patent on another technique that involves very thin glass fibers, being used as if there were a tape. To my knowledge, none of these techniques are used in production, and the archiving industry relies on normal disks and tapes.

And of course the format of the data must be readable in the future. Archiving is not a simple problem, is not solved, and unfortunately it seems there is no much interest.
There is a pretty large industry of archiving software and systems. About a decade ago I dealt with a handful of startups that were pretty successful in that space; I think they were called "Archivas" and "Permabit". I think they have been absorbed into larger companies in the meantime, but their products still exist. There is also extensive research on the problem of creating self-describing data formats, which allow data to still be decoded hundreds of years from now, when we have long forgotten the data structures in a JPG or PDF file. I think the experts in this field consider this to be a solved problem, although perhaps the solutions have not been widely deployed yet (that takes decades). My former colleague Raymond Lorie worked on this, and has a long list of publications that have helped solve this problem. Alas, he was taken from us by cancer shortly after his retirement; he was a real gentleman and a scholar.
 
so the failure of individual devices is merely an inconvenience and a cost. Data is then copied regularly to newer devices

A big, non affordable inconvenience and cost for a real archive. Also a risk.
Better is perhaps to bring to film what possible (documents).
 
For interactive use, shells/bash of course. I'm astonished by how elementary the command line skills are of even the most experienced sysadmins I've worked with. "<-arrowwwwwww--whoops too far--arroww->backspacebackspace[type]arrowwwwwwww->..." STOP. Didn't seem to hinder them too much since they were very good sysadmins, but still. So embarrassing watching them cd ; ls ; cd ; ls ; cd ; ls ; cd ; ls. Yikes.

How many people even know about history expansion and event designators in bash()? It's almost as bad as people using arrow keys to navigate editors/vim. o_O
 
With tcl you have the widget toolkit tk, a very comfortable way without much effort and lines of code of writing GUIs.
In fact, the tk toolkit can be used natively from Python scripts, too (it's called “tkinter”). So you can write GUI-based Python programs that work without change on BSD, Linux, Windows and Mac. I've learned tcl a long time ago, but since I switched to Python, I never looked back. It's so much easier to use, and you get results much more quickly. In fact, when you write down a draft of your program in pseudocode, it's already valid Python syntax. Well, almost. ;)
 
Not exactly, it seems the whole Tcl is bundled into pyton for making Tk as Tkinter available.
Of course, Tkinter uses libtk, which in turn depends on libtcl, so these are installed as dependencies.

Python also has interfaces for Gtk, Qt, FLTK and a few others if you prefer. But Tkinter probably has the smallest footprint and smallest number of dependencies.

I prefer the original and meagerer: Tcl. It is easy enough to use. And python, where indentation seems to have a semantic meaning, is strange to me.
Indentation is a natural and unambiguous way to structure code, and at the same time it leads to very compact and readable code. Actually I think that using things like curly braces or begin/end keywords is just an error-prone workaround from the “old ages” of programming languages. ;)

By the way, there's a small article (link) describing how indentation works in Python. It also takes care of some of the myths associated with it.
 
I think the issue for me when using Tcl or Python is that, yes you get a GUI library, but you loose easy access to all other native C libraries (which is still king in the world of *nix).

So in Python you would need to create a binding (https://docs.python.org/2/extending/extending.html) (which I find a too much effort to be worth it) or use an existing binding. These bindings however drag in all sorts of dependencies that I am not prepared to have. They also become obsolete and replaced far too often.

With C, you have Xaw (which is a little bit bare but good enough for scripts) but then direct access to other libs. I find this much cleaner.

I think the nicest solution for me would be allowing inline C within sh. i.e

Code:
#!/bin/sh

inline_c("

#include <X11/Xlib.h>

Display *d;
")

if [ -e "/some/file/path" ]; then
  inline_c("d = XOpenDisplay(NULL);")
  ...
else
  ...
fi

But that is either a pipedream or will simply require me to use a different shell and thus drag in more dependencies ;)
 
I think the issue for me when using Tcl or Python is that, yes you get a GUI library, but you loose easy access to all other native C libraries (which is still king in the world of *nix).
There are Python bindings for many C libraries.
So in Python you would need to create a binding (https://docs.python.org/2/extending/extending.html) (which I find a too much effort to be worth it) or use an existing binding. These bindings however drag in all sorts of dependencies that I am not prepared to have. They also become obsolete and replaced far too often.
You mean bindings for GUI toolkits, right? There is about a dozen of them (maybe even more). Among the smallest and lightest are Tkinter (Tk) and FLTK. They are lightweight and have very few dependencies, and they are portable beyond UNIX so you can easily write portable GUI programs that run on Windows and Mac, too.
I don't understand the part “become obsolete and replaced far too often”. I have Python+Tkinter programs that I wrote 15 years ago, and they still work today without change.
I think the nicest solution for me would be allowing inline C within sh. i.e
Please forgive me, but to my eyes that looks like combining two ugly languages, forming an even uglier chimera language.

That reminds me of dtksh. That was a ksh-based shell on Solaris with additional commands to create and manage X11 widgets. I worked with it a bit (about 20 years ago on Solaris' CDE); it was okay for simple scripting, basically to replace dialogues that would ordinarily use a curses interface. But it wasn't really suitable to write real GUI programs. After all, it was just a shell.

Today, if I need to have a small GUI dialogue within a shell script, I use x11/xmessage, x11/xprompt or x11/zenity (the former two are xaw-based and quite lightweight, the latter is a little heavier because it's based on Gtk, but it provides more possibilities and looks nicer). Or, if I need something more complicated, I write it in Python + Tkinter.
 
By the way, here is a simple shell script using a GUI dialog with xmessage. On my machine at home, it is called when I select the “shutdown” entry from the window manager's root menu.
Code:
#!/bin/sh -

BUTTONS=' Power-off :7,  Reboot :8,  Cancel :9'
DEFAULT='Cancel'

cat <<-EOM | xmessage -buttons "$BUTTONS" -default "$DEFAULT" -center -file -

        Please confirm shutdown of $(hostname).

EOM

case $? in
        7)      shutdown -p now ;;
        8)      shutdown -r now ;;
esac
 
I think the issue for me when using Tcl or Python is that, yes you get a GUI library, but you loose easy access to all other native C libraries (which is still king in the world of *nix).

So in Python you would need to create a binding (https://docs.python.org/2/extending/extending.html) (which I find a too much effort to be worth it) or use an existing binding. These bindings however drag in all sorts of dependencies that I am not prepared to have. They also become obsolete and replaced far too often.

With C, you have Xaw (which is a little bit bare but good enough for scripts) but then direct access to other libs. I find this much cleaner.

I think the nicest solution for me would be allowing inline C within sh. i.e

Code:
#!/bin/sh

inline_c("

#include <X11/Xlib.h>

Display *d;
")

if [ -e "/some/file/path" ]; then
  inline_c("d = XOpenDisplay(NULL);")
  ...
else
  ...
fi

But that is either a pipedream or will simply require me to use a different shell and thus drag in more dependencies ;)

It would be recommended as indicated above to avoid inline C code into SH code.
 
I don't use most shell functions, since I only need a few basic things --- I'm not a programmer. I like shells where I can use history, but discovered that using the command history didn't boost my day-to-day shell skills.

So I'll stick with the default sh and train myself learning and remembering more and more commands, look up the proper workings in a manpage, etc. Now after one year I'm a lot more comfortable using the shell, and it is better than clicking around in some GUI ;-)

6010
 
Back
Top