Either
sh shellscript.sh
or
./shellscript.sh
I presume you mean writing shell scripts that operate under the super user account - scripts are written for any reason to help automate tasks and make them much less error prone than issuing commands as a user. Running as the superuser merely means that the commands in the shell script require superuser priviledge to execute.
There is no answer to this question. Under UNIX and Linux, commands are either shell native or external programs found on the path (which usually includes /bin /sbin /usr/bin and ~/bin) Most UNIX and distros allow the admin to choose a shell program of choice and modify the contents of other directories and many admins allow individual users to change their personal shell and add additional executable files adding more commands. That being the case, theoretically any command can be valid under almost any UNIX or Linux. YMMV.
The issue is probably not with the the path or pythonpath environment variables, this is easily fixed and checked. Most likely the script contains a bug when executed under cron. Some shell commands give slightly different output when executed under cron even when you specify the same shell in crontab, for instance the date may be formatted differently, causing a bug in your program when using the datetime module for instance. I noticed this behavior in cron even when you tell cron to execute under the same shell (bash). So you will need to log any errors when running your python programs under cron and essentially debug them twice. Particularly if you are embedding shell commands in your Python scripts or calling bash in Python. Or develop your script while running it under cron to check for any odd inconsistencies. For those whose problem is not with path environment variables, log the interpreter errors and debug your program again. Ex crontab: */1 * * * * /usr/local/bin/script.py > /var/log/script_log.txt 2>&1 For example the shell running under cron formatted the date differently with the output of some shell commands (all environment paths were consistent between the two shells): Sun Jan 18 12:00:59 2014, instead of Sun 18 Jan 2014 12:00:59
The kernel.
"No. There is no Linux-native version, and it does not function under Wine." Tally 7.2 does have a Linux version with its CD. The installer and other docs are placed under a folder named Linux. I have installed it under CentOS and is working just fine.
The Linux kernel is licensed under the GPL version 2.
mkdir aptech/Linux
Yes, Linux is an open source kernel released under the GPL.
Yes and no. Linux will not run Windows applications by itself, however, there are ample tools written for Linux that permit you to run Windows applications on Linux. The open-source WINE software will run a majority of Windows software on Linux. You can even configure Linux to automatically recognize Windows applications and use WINE to run them. Alternatively, there's a wide variety of virtual machine products that permit you to run the Windows operating system as an application under Linux, and, in turn, any Windows applications inside the Windows virtual environment. Finally, some "Windows applications" are written in .Net or Java and can be run directly under Linux using mono and java respectively (albeit, some .Net applications will not yet run under mono).
yes
Yes, CA-dBFast works under Linux Wine program, Although, it would be better under a Virtual Machine running Windows.
Yes, but they are kinda hidden under the shell.