MicroEdge, Inc. has released a version of SlickEdit for Linux. SlickEdit is a character-based programmer's editor running on a variety of platforms and it should appeal to developers who work in more than one environment. The current list price is US $195.
For a programmer arriving from a DOS environment, SlickEdit provides a comfortable transition. Instead of arcane keystrokes and endless keyboard remapping, the user is presented with an unobtrusive menu system which may be later discarded. Pressing F1 brings up the help system and the behavior of particular keys, such as insert and delete, act in the manner to which the DOS user is accustomed.
SlickEdit can be considered a fairly complete editor in that it provides most of the features necessary for productive coding. It has full undo and redo capability, even past successive file saves. Multi-file search and replace is supported along with regular expression searches. Cut and paste operations may be performed on marked lines, blocks, and columns. Multiple clipboards of marked text are maintained. A Rexx-like macro language provides over 850 callable editor functions.
A single diskette installs SlickEdit onto /usr/bin and /usr/lib/slick by default, consuming about 2Mb of disk space. Less space is necessary if you choose not to install all the macro files. The SlickEdit executable is only 260K. A 400-page perfect bound manual is included with the application.
There are three ways you may wish to use SlickEdit on a Linux system: console, terminal, or xterm. Each has its own peculiarities and you will probably want to create a separate keyboard description file for each. A key mapping utility called genktab allows you to tell SlickEdit what to expect when a key is pressed. A readable keyboard description file is compiled into a “.tab” file. Another utility, showkey, is provided to help you determine what sequences your terminal is generating.
Most of the common terminal types are included in the default keyboard description file, including vt100 and xterm. To work with xterm, the file /usr/lib/slick/xdefault must be appended to the .Xdefaults file in your $HOME directory. A special xs script is included to avoid the initial configuration hurdles. Under xterm the window can be dynamically resized with the mouse, but the mouse cannot be used to manipulate text within the screen. MicroEdge has stated they intend to add mouse support for Unix in a future version of SlickEdit.
Under console mode, SlickEdit is virtually indistinguishable from its DOS version. The Alt-F1 thru Alt-F4 keys may need to be remapped to provide functions such as MOVE-EDGE and DELETE-ADJACENT, since most Linux systems use these key combinations to provide virtual terminals. You also can perform these operations from the SlickEdit menu or configure the Alt key for a non-console terminal as described below.
Setting up a terminal to act the way a normal DOS user expects is challenging, especially for a text editor. The Alt key has no counterpart with most terminals in standard use today. MicroEdge works around this problem by defining the backtick (`) key as the Alt key for a non-console, non-xterm terminal. In practice this adaptation is easy and natural to use. To enter an actual backtick, a ^Q ` sequence is entered.
Another potential problem with using a terminal is common to many Unix applications^-namely the confusion resulting in sending an escape sequence (say, F1 under ANSI emulation) and a literal escape (0x1b) character. This is not peculiar to either Linux or SlickEdit, but it is more noticeable in text editing applications where you're likely to be pounding the arrow keys a lot. SlickEdit attempts to alleviate this by allowing the user to specify a delay for an ambiguous key sequence. On other Unix systems I have noticed that this is not always 100% successful, especially if you are running telnet through through heavily loaded systems. However, my limited use on Linux uncovered no problems.
If you purchase SlickEdit, you have, at a minimum, two expectations: ease of use and technical support. After configuration, SlickEdit has very few surprises. Getting to the point that you are satisfied with your configuration, however, may require a phone call to Technical Support. My prior experience with MicroEdge's support has been very good, and this time was no exception. Basically, I wanted true 8-bit line drawing characters rather than the stodgy hyphen, plus, and vertical bar (- + |) symbols displayed. My call was returned in 30 minutes. After ascertaining what I needed, the specialist offered to e-mail me the necessary file, with the assurance that I could call him back if there were any further problems. My ANSI.DAT file arrived later that day and everything worked as expected. MicroEdge also supports a CompuServe forum: “go slickedit”.
My overall impression is that MicroEdge has done an excellent job in porting SlickEdit to Linux. I have written many lines of code over the past two years with the SlickEdit family of editors on a variety of platforms. There are certainly other freeware alternatives to the venerable vi and Emacs editors, but I find my level of productivity is raised (and frustration lowered) by using SlickEdit.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide