GitLab and GitHub both support coloring their output with escape sequences.
But GitLab (I didn't test the default TERM value in GitHub) sets TERM=dumb which is a good default, but techincally incorrect, I guess, as it is misleading about the capabilities.
Is there any predefined terminfo entry which describes the GitLab terminal emulation capabilities correctly, or just better than dumb?
If not, is there any way to systematically test the capabilities and write a custom definition?
I understand that a lot of software doesn't use termcaps, and maybe only understands a hardcoded list of xterm, dumb and linux. My goal isn't making it actually working with pre-existing software, there are adhoc options for that often (such as --color=always)
You could define a simple termcap that at least defines the known ANSI color capabilities, but it would probably need to define all other caps as unsupported, at least until more light can be shone on the other underlying capabilities of GitLab runner terminals.
Example of the supported ANSI color sequences in GitLab CI Runner "terminals": https://gitlab.com/dgoo2308/readability_colors/-/blob/master/.gitlab-ci.yml
Related
Win32::Console::ANSI enables by default a ANSI(Win) to OEM(Dos) mapping. When I use Win32::Console::ANSI in a CPAN module should I keep this mapping or should I disable this mapping with \e(U?
The documentation outlines the reason this is the default:
It is useful because one types the script with a Windows-based editor
(using a Windows codepage) and the script prints its messages on the
console using another codepage: without translation, the characters
with a code greatest than 127 are different and the printed messages
may be not readable.
That seems to be a sensible default for an ANSI console emulation, as it aims to avoid unreadable messages. If, when people are using your CPAN module, they can reasonably expect an ANSI console, maybe it's wise to leave the defaults as they are. What you might want to do is allow people to choose the behaviour as an option when they load/configure your module. But in any case, make it really clear in the documentation what you're doing and why.
I'm writing a Common Lisp application. I'd like to have a Bash script which will serve as the entry point to the application. Currently, I've written the script so that the user must pass in their name of the Common Lisp implementation to run it, so I would write ./script.sh clisp for GNU CLISP but someone with SBCL would have to write ./script.sh sbcl. This is necessary since, unlike languages like Python and Ruby, Common Lisp implementations do not have any standard name or standardized way of invoking them.
Is there any trick to detecting which Common Lisp implementation is installed, perhaps an environment variable or something? Basically, I'm looking for something better than forcing the user to pass in the name of the implementation.
You could use Roswell, which provides ways to set the implementation on a user or invocation level. You still need wrapper scripts, but roswell standardizes them.
Install the cl-launch Unix utility program which implements the abstraction described in #bishop's answer. The utility will detect most implementations of Common Lisp and can be used to execute a script or dump an executable which calls the content of a script (loads faster).
TL;DR: I don't think there's a trick, but you need not require the clisp interpreter on every invocation.
This is a relatively common pattern: you have a bash script that depends upon a certain executable being available, and it may well be available, but in different locations, possibly with the user having their own compiled version and/or the system having several alternatives.
The approach I've seen boils down to this algorithm:
If there is an environment variable that specifies the full path to an executable, prefer that
Otherwise, if there is a configuration file in the user's home directory that specifies the location, and possibly other parameters, prefer that
Otherwise, if there is a configuration in /etc that specifies the location, and possibly other parameters, prefer that
Otherwise, ask the system package manager to list the packages matching your application's typical installation names
The first three are easy enough to implement using the bash test functions and, I'm guessing, if you got this far you know how to do that. (If not, ask and I'll post examples.)
It is the fourth point that becomes interesting. There are two variables to deal with. First, determining the package manager in the installed environment. There are no shortage of these, and I've seen both table approaches (mapping OS to a package manager) and inquiry approaches (looking for executable that match expected names like rpm, yum, emerge, etc). Second, determining the package name appropriate for your package manager. This too can be tricky. On the one hand, you're probably safe iterating through the list of known executable and grepping the list. On the other hand, your package manager may provide "virtual" or "alternative" packages that generically provide a service, regardless of the specific implementation. For example, you could grep the portage tree for dev-lisp and be reasonably sure to find one installed package.
The easiest case is when your script is meant to be run in a small number of well-known environments: implement the one or more of the first three points to the let the user override the script's auto-selection, then your script's auto-selection just iterates over the known alternatives in your known environment until it finds one it prefers.
The hard case is when you have to support multiple environments. You end up writing an abstraction layer that knows about the different possible package managers and how to interrogate those package systems for various packages, either at a generic level or for specific packages. Having done this for a script set that deployed on AIX, HP-UX, Solaris, a couple of Linux distros, and cygwin Windows I can say: not fun.
As I read your question, you have a script that will be distributed to different users' machines whose environments you don't control. The only requirement of these target machines is they have bash and at least one Common LISP interpreter installed. From this, I inferred you couldn't install any loaders. However, if you can install, require, or detect the presence of any of the launchers mentioned in other answers, that will certainly save a ton of work.
I see a lot of places in my office where ant tasks are used to move files from one place to another and also do some tasks on these files.However all this can be done with shell scripts.
My question is ,
In what cases is ant preferred over shell scripts ?
What are the benefits of using ant over a shell scripts for doing same set of tasks.
One advantage ant has is that it works on all platforms,other than that are there any performance related advantages ?
Your question as to why ANT should be preferred to shell scripts is two-fold:
ANT is a tool that has achieved widespread adoption and is likely to
be already installed on a developer's workstation. Compared to one
of it's main predecessors, make, ANT is a lot more standardized and
cross-platform.
ANT is a tool familiar to developers. Used to build their code so they will often extend the ANT script to deploy their application as
well. Indeed many vendors offer ANT tasks for this purpose.
There are no performance benefits, really. Java is slow for command-line usage.
But..... I would advise against playing the "performance" card. Let's pretend that your application does not support windows (Which is odd considering a Java application should support all plaforms...): I have seen shell script driven deployments decend into chaos attempting to reconcile the various ways different unix operating system commands work. Commands like "tar", "awk", etc can be subtly different which leads to additional platform support logic in your script.
In conclusion I would use neither. I choose a hybrid approach of using groovy for general scripting. It is a java based scripting language and embeds the full power of ANT. Being a java based scripting language means it will work on all platforms. In the interest of fairness it should also be noted that there are other language options. Ruby is certainly worthy of mention since it has spawned a set of configuration management technologies that are well worth evaluation. (See Chef and Puppet)
In practice, it boils down to Windows support. If you're in a Unix shop and don't want to introduce new stuff to devs, there are two alternatives i've used with success:
Plain old shell script with Git Bash. Git Bash comes with the Git windows distribution (http://git-scm.com/). If you're doing automation, you can launch shell scripts like so: "C:\Program Files (x86)\Git\bin\sh.exe" --login -i -- ./BUILD
Node script. Again it's one easy installer, it's javascript, and you can use something like ShellJS (https://github.com/arturadib/shelljs) to get very close to Unix shell script / Makefiles.
What are the code tutorial shells called that are used on various websites such as codecademy, codeschool, mongo db, try ruby etc.
Is there a service for building and maintaining these things? Or is it something you build yourself?
I found ShellInABox but it doesn't seem exactly like the only one people are using?
These are colloquially known as "web REPLs" (a term meaning "Read/Eval/Print Loop").
They can be distinguished by unrestricted ones used for debugging by describing them as "sandboxed". There is not a single, universal toolkit used to build these, though you may find repl.it (which uses a number of interpreters compiled to javascript to run client-side REPLs for numerous languages) interesting.
I'm now learning Tcl/Tk, but as I'm running Windows, I want to create a fully featured(professional) development environment for this language, but I need to know:
Which tools I need to install(first of all)?
What are the IDEs that support Tcl/Tk development?
What is the best text editor to develop in?
Where I can find some librarys for it(if exists)?
It's possible to do some web applications with it?
It uses CGI?
Start off by installing ActiveTCL. It is free and includes TCL and TK bindings. If you have a favorite text editor you can use that. Make sure you have syntax highlighting. If you want something more advanced, I'd recommend Komodo. It is by active state and has a free version. It semantically understands TCL, so it is more intelligent than a standard text editor. For example it highlights syntax errors while you code.
Now write some code and spread the TCL love!
For an interactive Tcl shell, use TkCon
For an editor, I use Komodo or Vim
For web apps, there are FrameWorks, servers: TclHTTP, Aol Server, Apache modules, and of course CGI
For a text editor I would recommend trying jEdit; it has TCL syntax highlighting. When installed I would also recommend installing the following plugins (which can be done via the built-in plugin manager):
Project Viewer: Allows you to organise your files into projects, which gives it more of an IDE feel.
Editor Scheme: Gives you a set of pre-defined syntax highlighting colour schemes to choose from. My preference is for "zenburn".
As Byron mentioned, ActiveTCL is the place to start when using TCL on Windows. As for a text editor, I personally like SciTE, but any text editor that will do syntax highlighting will do (code folding helps as well).
The TCL wiki has the following page regarding IDEs: http://wiki.tcl.tk/998
If you are in need of a library providing specific functionality, I would first check the TCl wiki. There is no central repository of TCL extensions, but the wiki seems to be the central repository of TCL knowledge.
Yes, you can use TCL for web-based projects. You can find a bit of info here regarding CGI and TCL. Some webservers (AOLServer for instance) have a built-in TCL interpreter.
Others have already mentioned TkCon but most people don't utilise the full power of TkCon. It is much more than a REPL loop (for that you could have just used tclsh or wish). My favourite feature is TkCon's edit command.
Basically:
edit some_file.txt
lets you view and edit files.
set my_variable "some value"
edit my_variable
lets you view and edit the content of a variable, even arrays
proc my_function {} {}
edit my_function
lets you view and edit the body of a proc. In fact, this is how I usually write non-trivial procs in TkCon.
If you're going to write code that needs Windows-specific functionality, you will definitely want to get TWAPI the Tcl Windows API library.
With regards to the mentions of ActiveTcl - ActiveState (the creators of ActiveTcl) have been developing an extension repository. Certainly there are extensions which do not (yet) appear there, but there are over 3000 entities in their repository at this time, so many extensions are present there. ActiveTcl comes with a program called "teacup" which provides a command line interface to the repository, allowing you to install specific extensions (or, if you are like me, allowing you to install all the extensions relevant to your platform).
The Tcler's wiki has a number of references to additional tools and extensions. However, your favorite web search engines are likely to turn up utilities, tools, extensions, and applications not yet documented on the wiki or added to the ActiveState repository.
MyTcl is a fairly nice IDE with a Tcl environment included, autocomplete, syntax highlighting, debugging, etc. It has a similar look and feel to Visual Studio. The homepage is in Korean, but it's not too hard to find the download.