# What is your favorite shell?



## justinnoor (Jan 7, 2019)

What shell do you use with FreeBSD? Why do you use it? What do you like about it?

I’m currently using FreeBSD sh(1) because it’s lightweight, simple, and for the most part, compatible with Bash (the opposite is not true), which is the lingua franca in Linuxville.


----------



## Vull (Jan 7, 2019)

At the command prompt, I generally use whatever shell the OS has as a default.  For scripts I use the shebang line #!/bin/sh because it's cross-platform compatible and POSIX-compliant. Sometimes as the FreeBSD super-user I'll use /bin/sh in a secondary shell, by entering the commands `/bin/sh` followed by `SHELL=/bin/sh`. My only (good) reason for doing this is to allow me to copy and paste environment variable assignment statements from text files without editing in the `set` command required by the native root /bin/csh shell. I can then return to the /bin/csh shell at any time by entering the `exit` command. I don't think it's a good idea to change the default shell, so I've broken the habit of doing it, particularly for the root account, where I've never done it.

In the past I've written scripts that required bash, and some that required sudo, but now I'm in the proceses of rewriting them all to use sh and su instead. I would have saved myself some trouble if I had only done it that way in the first place, but as it turns out it's really not that much trouble to fix them. IMO and for my purposes, it's well worth whatever trouble it takes to improve cross-platform compatibility.


----------



## justinnoor (Jan 7, 2019)

Interesting!


----------



## drhowarddrfine (Jan 7, 2019)

What Vull describes is the smart way to do things. Much of which is described in the Handbook.


----------



## SirDice (Jan 7, 2019)

I use tcsh(1) for interactive use, sh(1) is only used for scripting.


----------



## forquare (Jan 7, 2019)

For my day-to-day interactive use, I use shells/zsh (with vi mode enabled).  I was introduced to UNIX via shells/bash and shells/ksh on Solaris.  When I passed over to Linux for a time, bash was already there so I used it. 

I have a number of friends that use ZSH, so I decided to give it a go and found that (certainly at the time) it was more featureful and flexible in configuration than bash.  Also it is MIT licensed, and at the time I was trying to reduce the amount of GPL applications I was using.
I tried oh-my-zsh at the start, but it was too much additional 'stuff' to comprehend, and didn't seem to offer _me_ additional, useful, features to trade off learning them.  Also, since I work with many shells in a given day which I can't choose and customise, I try to keep my personal shell customisations fairly simple to avoid additional friction on other systems. 

For scripting I always use sh(1).  For root's interactive shell I've always used tcsh(1), aside from when I want to do longish "one liners" or looping, then I revert to sh(1) interactively much like Vull described, because I use tcsh(1) so rarely I easily forget how to do things like looping in it, and reverting to sh(1) is quicker than checking a man page.


----------



## olli@ (Jan 7, 2019)

Another zsh user here.

In my early UNIX days (that was mostly SunOS) I used csh and tcsh, because it was the default for new users at the place where I worked. But soon I noticed that it sucked for scripting, so I switched to bourne shell (to be more exact: ksh) for scripting. And then I noticed that it sucks to use different shells for scripting and interactive use. Then I started looking for a better interactive shell.

First I looked at bash, because many people used it. But I never was the guy who used something just because many other people did … So I looked further and tried several other bourne-compatible shells. And finally I settled for zsh, because it was the most flexible regarding its configuration. For example, it is _way_ ahead regarding the possibilities configuring your shell prompt, the editor shortcuts, tab completion and various other things. I can work with zsh _much_ faster and more efficient than with any other shell.

I still use the “normal” /bin/sh for scripting (unless I decide that Python is better for the job at hand). The nice thing is that zsh has an sh-compatibility mode (it can also emulate ksh), so you can easily copy&paste fragments from scripts to the command line, try them out, improve them, and copy them back to your script.

By the way, I have an alias `su="su -m"`, so when I switch to root, I get the same shell that I have as normal user, i.e. zsh, without having to modify root's login shell. Note that – for various reasons – it is usually _not_ a good idea to change root's login shell.


----------



## Vull (Jan 7, 2019)

Thanks for the tip *olli@* - Using su -m to retain the non-root user's shell is quicker than the way I've been doing it.


----------



## Sensucht94 (Jan 7, 2019)

I use mksh(1) as interactive shell and sh(1) for scripting; I love playing with shells/osh too, the Unix V6 Thompson shell revamped


----------



## serpent7776 (Jan 7, 2019)

tcsh(1)() for interactive use. Looked at shells/mksh, but it doesn't support programmable tab completion which scared me.


----------



## humphrayLegare (Jan 7, 2019)

zsh ! Reason why can be found here : https://github.com/robbyrussell/oh-my-zsh


----------



## tedbell (Jan 7, 2019)

zsh as well with oh-my-zsh for the fish style plugins.


----------



## BSD User (Jan 25, 2019)

For interactive use - sh
For everything else - Perl


----------



## ralphbsz (Jan 25, 2019)

Scripts: Plain sh.  If the script has to be portable, I actually spend some effort with the documentation for the V7 Korn shell to make sure I don't use any modern extensions.

Interestingly complex scripts: Python.  I'm finding that anything that's longer than 30 or 50 lines is better written in an intermediate-level language, you end up with cleaner, more portable code with fewer bugs.  That's particularly important since scripts are hard to completely debug (injecting errors is a lot of extra work, and code path that are not tested can have blatant syntax errors and typos, since there is no compiler to do the first level of quality control).  I used to also use Perl, and even Ruby and before that Rexx for a while; today I'm down to just Python.

Interactive: Used to be tcsh, but about 10 years ago I switched to bash for every machine.  It's relatively featureful, supported on every OS I use (I do a lot of work on Linux), and has the same syntax as sh, so the difference to scripts isn't too large.  That was the real reason I abandoned tcsh: The gap in language between the interactive commands and scripts was annoying me.

For interactive use, this is really just a question of personal preference (or religion), to each his own.  But it is not just personal preference for script-writing: abuse of specific features (common in Linux where scripts depend on bizarre features that only exist in bash) is just bad software engineering.  I've dealt with a system that had a quarter million lines of scripts (the single largest one was 18K lines), written in a bizarre custom shell that derives from pdksh, and was a maintenance nightmare.  Much better to use a common base standard and stay portable.


----------



## alexseitsinger (Jan 25, 2019)

I stick to BASH for my interactive shell. SH for root and (most) scripts. Other more complicated scripts are done with Python.


----------



## rigoletto@ (Jan 26, 2019)

*Interactive:* I've being using tcsh(1) during the last years, before used to shells/bash on Linux, but yesterday I switched to shells/zsh and I am still configuring it but enjoying in general.

*Script:* I use sh(1) but I just started learning OCaml, and I also learned a bit about using it as script language. I don't know a lot of about it yet but looks good, and I will probably switch to it at some point. HERE and HERE.


----------



## fraxamo (Jan 26, 2019)

rigoletto@ said:


> I just started learning OCaml



I'm a big fan of OCaml and typed FP in general. One of the best OCaml resources I've come across recently is this online book.


----------



## Ogis (Jan 26, 2019)

I am a fan of csh shell.


----------



## rigoletto@ (Jan 26, 2019)

fraxamo said:


> I'm a big fan of OCaml and typed FP in general. One of the best OCaml resources I've come across recently is this online book.



I've got two books (I started reading the first):



> Hitington J. - OCaml from the Very Beginning - 2013
> Minsky Y., Madhavapeddy A., Hickey J. - Real World OCaml - 2013



Now I will add the one you indicated in my _shelft_ too.

*[EDIT]*

Now I need to find out what is that font used in the title "Functional Programming in OCaml". 

Ok, found it. Play - looks good to use with x11-fonts/ohsnap.

Thanks!


----------



## fraxamo (Jan 26, 2019)

rigoletto@ said:


> I've got two books (I started reading the first)!



Yes, the first book is very good. However, the second book, Real World OCaml (the physical book) is now considered out of date. You'll find an online beta version of the second edition here.


----------



## Spartrekus (Jan 27, 2019)

My favorite shell is the first shell existing from Sir. Thomson:

*osh*
(tsh)
https://github.com/eunuchs/tsh
https://etsh.nl/


----------



## yuripv (Jan 27, 2019)

bash, for no apparent reason, it's (almost) POSIX-compatible for trying out scripts, and pretty good as interactive.

OTOH, there's a proposal for importing mksh to base system -- if it works out, I'll most likely will be happy to just use it instead.


----------



## mod3777 (Jan 29, 2019)

Vull said:


> At the command prompt, I generally use whatever shell the OS has as a default.  For scripts I use the shebang line #!/bin/sh because it's cross-platform compatible and POSIX-compliant. Sometimes as the FreeBSD super-user I'll use /bin/sh in a secondary shell, by entering the commands `/bin/sh` followed by `SHELL=/bin/sh`. My only (good) reason for doing this is to allow me to copy and paste environment variable assignment statements from text files without editing in the `set` command required by the native root /bin/csh shell. I can then return to the /bin/csh shell at any time by entering the `exit` command. I don't think it's a good idea to change the default shell, so I've broken the habit of doing it, particularly for the root account, where I've never done it.
> 
> In the past I've written scripts that required bash, and some that required sudo, but now I'm in the proceses of rewriting them all to use sh and su instead. I would have saved myself some trouble if I had only done it that way in the first place, but as it turns out it's really not that much trouble to fix them. IMO and for my purposes, it's well worth whatever trouble it takes to improve cross-platform compatibility.



You are not alone.. I use sh for scripts, tcsh for interactive, inside jails, zsh


----------



## hruodr (Jan 31, 2019)

As login shell `tcsh`, only because `bindkey -k up history-search-backward`, otherwise I would preffer to use something meagerer. For trivial system scripts I use `sh`: I never learned to realy program with `sh`, I find it idiosyncratic. For scripting  programming I use tcl ()and I can recommend it for many reasons.


----------



## kpedersen (Jan 31, 2019)

*bash* and *ksh* for interactive use

*sh* for simple scripts (lowest common denominator / portability)

*C* for anything I cannot script (i.e X11). I don't bother with Python, perl, java and all that stuff because I despise pointless bindings and dependencies which can simply be avoided by using C.


----------



## hruodr (Jan 31, 2019)

kpedersen said:


> *C* for anything I cannot script (i.e X11).



With *tcl* you have the widget toolkit *tk*, a very comfortable way without much effort and lines of code of writing GUIs.

From *tcl* scripts you can also call your *C* programs, and then connect them to the GUI.


----------



## kpedersen (Jan 31, 2019)

hruodr said:


> With *tcl* you have the widget toolkit *tk*, a very comfortable way without much effort and lines of code of writing GUIs.



True but I kinda got burned by *dtksh* which allowed *ksh93* to connect to Motif widgets. After the deprecation of Solaris 10, I had to wait many years to be able to use my old GUI scripts again XD.
At least being open-source *tk* will be around for many years to come, but I would rather avoid dependencies for my own personal convenience scripts. X11's Xaw provides all I need for a button / textbox for example.


----------



## Spartrekus (Jan 31, 2019)

bash is very slow and heavy


----------



## Spartrekus (Jan 31, 2019)

kpedersen said:


> *bash* and *ksh* for interactive use
> 
> *sh* for simple scripts (lowest common denominator / portability)
> 
> *C* for anything I cannot script (i.e X11). I don't bother with Python, perl, java and all that stuff because I despise pointless bindings and dependencies which can simply be avoided by using C.



Come on, all programmers use heavy advanced programming languages for easy programming. 

You cannot use C on Android,... rapid software developments and customer implementations. There is no money there.


----------



## hruodr (Jan 31, 2019)

*kpedersen*, tk is one of the oldest toolkits, tcl/tk scripts may run on unixoides, Windows and Mac.

*Spartrekus*, scripting is more expresive: a script (including sh scripts) for example can dynamically write code and interpret it. Sure, a C program can also write a file and with system calls compile and run it, but that is not very elegant, not so expressive, not so readable. One uses C and scripting for different purposes.


----------



## kpedersen (Jan 31, 2019)

Spartrekus said:


> You cannot use C on Android,... rapid software developments and customer implementations. There is no money there.



Luckily the game industry is one of the last bastions of light where much of the engine work needs to be native C++ (with some C). Thus on Android the Google NDK (or Intel NDK) is king. There is still hope!


----------



## hruodr (Jan 31, 2019)

By the way: http://www.androwish.org/index.html/home


----------



## Spartrekus (Jan 31, 2019)

hruodr said:


> *kpedersen*, tk is one of the oldest toolkits, tcl/tk scripts may run on unixoides, Windows and Mac.
> 
> *Spartrekus*, scripting is more expresive: a script (including sh scripts) for example can dynamically write code and interpret it. Sure, a C program can also write a file and with system calls compile and run it, but that is not very elegant, not so expressive, not so readable. One uses C and scripting for different purposes.



*1. TK*
Precautions with TK. tk is quite complex, it looks to me more like a possible «Vipers' Tangle», «The Knot of Vipers». I likely prefer following solution, better to use C on top of X11. Anyhow both are outdated and will likely no longer exist some day. FLTK??

*2. C versus Scripting*
Scripting has its own strengths. Too much Scripting can slow down your system heavily. C has its own strengths as well. Both are necessary, actually scripting can be removed fully. Actually C too. "Most modern operating systems are written in C/C++. That's very useful when portability and code-maintainability are crucial, but it adds an extra layer of complexity to the proceedings. " He is very right, there is lot of complexity using Clang or the gcc compilers.
Yeah, assembler would be only what we need. Asm : http://mikeos.sourceforge.net/write-your-own-os.html

Edit:
*3. Hope *
there is no hope for Android : it  .... runs  ... ultra ... slow as hell.


----------



## Crivens (Jan 31, 2019)

I prefer the shell with a ghost in it 

Otherwise, csh for interactive and sh for the rest.


----------



## Spartrekus (Jan 31, 2019)

Crivens said:


> I prefer the shell with a ghost in it


what does it mean?


----------



## kpedersen (Jan 31, 2019)

Spartrekus said:


> what does it mean?



Crivens is obviously referring to the infamous Ghost Clam series of anime.


----------



## Spartrekus (Jan 31, 2019)

what about my ghost on terminal, cute unix ghost,  (ndesk for ncurses), moving from left to right ... :


----------



## hruodr (Jan 31, 2019)

Spartrekus said:


> Too much Scripting can slow down your system heavily.



Why? I run my scripts when I need to run them.

If you like C, you can very easily extend Tcl with C programming. You write the critical parts in C, pack them as new Tcl commands, and the rest of the uncritical things (including the GUI that does not need to be much faster than humans) in Tcl/Tk. This has many advantages.

But even if you write big scripts with Tcl/Tk you get lightweight programs.

The well known sqlite3 database began as tcl extension and has a very nice tcl API. Tcl and sqlite3 work very good together. I got the feeling of how reliable sqlite3 is when I learned about this nice program:

https://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki


----------



## trev (Feb 1, 2019)

Interactive tcsh(1)
Scripts sh(1)


----------



## hruodr (Feb 1, 2019)

*kpedersen*, *Spartrekus* prehaps the following is a reason to use tcl:

https://www.dreamsongs.com/WIB.html

The sentence "Unix and C are the ultimate computer viruses" is a little exaggerated.


----------



## Eric A. Borisch (Feb 1, 2019)

*sh* for scripting
*fish* for interactive use. (Don't knock it till you've tried it.)


----------



## Spartrekus (Feb 2, 2019)

hruodr said:


> *kpedersen*, *Spartrekus* prehaps the following is a reason to use tcl:
> 
> https://www.dreamsongs.com/WIB.html
> 
> The sentence "Unix and C are the ultimate computer viruses" is a little exaggerated.



could be possible. In fact, Lisp always existed. tcl might be good.
Ideally we should use assembler


----------



## Crivens (Feb 2, 2019)

Spartrekus said:


> could be possible. In fact, Lisp always existed. tcl might be good.
> Ideally we should use assembler


Ahmmmm NO.
Ideally we should identify the 5% of the code which eat up 60% of the time and tune that code. Find the 1% that has 40% of the time and maybe use assembler for that. What you might gain from using assembler for more than a few very hot spots will be spent in debugging and porting. Also you need to re-tune everything by hand when the silicon changes.


----------



## kpedersen (Feb 2, 2019)

Yup, as far as shell scripts go... I'm possibly not going to use assembly any time soon 

I guess I'm just lazy XD


----------



## hruodr (Feb 2, 2019)

Lisp is after FORTRAN the second oldest high level programming language, the elementary part is easy to implement and it is powerful for its purpose. The later extensions are sure an alternative to scripting languages, but the syntax is not very readable. Some people say that LISP means: List of Insipid and Stupid Parenthesis.

Gnu Guile, a Scheme (Lisp dialect) interpreter, was mean as a concurrent to Tcl and is as Tcl also extensible with C programming. But, as far as I know, not much people use Guile, not even GNU emacs, but a lot use Tcl.

Tcl allow also recursive functions and depending on your programming style may seem to Lisp. I personally try to avoid recursiveness.

No, I do not follow *Spartrekus* with "Ideally we should use assembler". There are many, many reasons why this is not ideal. *Crivens* mentioned only one. One could also say, ideally we should save all electronic written documents as bitmap (I save my TeX code, not even as ps/PDF).

But the article I quoted (Worse is better) is not about Lisp, or not only about it, and it brings a point against C for everything.


----------



## Spartrekus (Feb 2, 2019)

Crivens said:


> Ahmmmm NO.
> Ideally we should identify the 5% of the code which eat up 60% of the time and tune that code. Find the 1% that has 40% of the time and maybe use assembler for that. What you might gain from using assembler for more than a few very hot spots will be spent in debugging and porting. Also you need to re-tune everything by hand when the silicon changes.



Assembler allows to spend (lot of) time on a smaller approach, which could gain in efficiency for a given (small) base operating system.


			https://www.tuhs.org/cgi-bin/utree.pl?file=V1
		



			MikeOS - simple x86 assembly language operating system


----------



## hruodr (Feb 2, 2019)

*Spartrekus*, perhaps you know this wiki: https://wiki.osdev.org/Main_Page

But till now you have not given real arguments for your absolute C/assembler view, but the opposite: when you write the ideal is other thing of what you do, you are recognizing that the non-ideal has advantages.


----------



## Crivens (Feb 2, 2019)

hruodr said:


> One could also say, ideally we should save all electronic written documents as bitmap (I save my TeX code, not even as ps/PDF).


I know of one company where the long term archive for safety relevant stuff (about 30 years storage) ONLY accepts ASCII and PNG. Want to hand in your presentation, .doc or .pdf? Print it out page for page.


----------



## hruodr (Feb 2, 2019)

*Crivens*, this is perhaps offtopic inside of offtopic thread. 

I begun to use again FreeBSD because ZFS hails files using redundancy. Although ZFS is bloated for an archiving file system, I think (or hope) 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? 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.


----------



## Spartrekus (Feb 2, 2019)

hruodr said:


> *Crivens*, this is perhaps offtopic inside of offtopic thread.
> 
> I begun to use again FreeBSD because ZFS hails files using redundancy. Although ZFS is bloated for an archiving file system, I think (or hope) 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? 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.



It is a consequence of what is today considered as important.


----------



## hruodr (Feb 2, 2019)

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.


----------



## kpedersen (Feb 2, 2019)

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.


----------



## Spartrekus (Feb 2, 2019)

> 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.




kpedersen said:


> 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.
> 
> ...



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?


----------



## ralphbsz (Feb 2, 2019)

hruodr said:


> ... 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.


----------



## hruodr (Feb 3, 2019)

ralphbsz said:


> 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).


----------



## Spartrekus (Feb 3, 2019)

My favorite shell is _sh_ and also the original work of Thomson : original shell.
The _osh_ package provides two ports of the original /bin/sh from
Sixth Edition (V6) UNIX (circa 1975)
Jeffrey Allen Neitzel
http://v6shell.org/ 

Have you ever tried to make it work?








						GitHub - s3lase/v6shell: V6 Thompson Shell Port
					

V6 Thompson Shell Port. Contribute to s3lase/v6shell development by creating an account on GitHub.




					github.com
				




I find _bash_ quite slow to be used.


----------



## linux->bsd (Feb 4, 2019)

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.


----------



## olli@ (Feb 4, 2019)

hruodr said:


> 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.


----------



## hruodr (Feb 4, 2019)

olli@ said:


> the *tk* toolkit can be used natively from Python scripts



Not exactly, it seems the whole Tcl is bundled into pyton for making Tk as Tkinter available. Hence, you can run Tcl scripts from python: https://wiki.tcl-lang.org/page/Python

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.


----------



## olli@ (Feb 4, 2019)

hruodr said:


> 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.


----------



## kpedersen (Feb 4, 2019)

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


```
#!/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


----------



## olli@ (Feb 4, 2019)

kpedersen said:


> 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.


----------



## olli@ (Feb 4, 2019)

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.

```
#!/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
```


----------



## Spartrekus (Feb 4, 2019)

kpedersen said:


> 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.
> 
> ...



It would be recommended as indicated above to avoid inline C code into SH code.


----------



## meine (Feb 5, 2019)

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 ;-)


----------



## bookwormep (Feb 7, 2019)

I use the shells/bash ; as well as, shells/tcsh.


----------

