consular 1.0.0.rc1
Sign up to get free protection for your applications and to get access to all the features.
- data/.gitignore +5 -0
- data/Gemfile +4 -0
- data/Gemfile.lock +28 -0
- data/LICENSE +20 -0
- data/README.md +437 -0
- data/Rakefile +9 -0
- data/Termfile +7 -0
- data/bin/consular +13 -0
- data/consular.gemspec +40 -0
- data/lib/consular/cli.rb +220 -0
- data/lib/consular/core.rb +65 -0
- data/lib/consular/dsl.rb +220 -0
- data/lib/consular/version.rb +3 -0
- data/lib/consular.rb +68 -0
- data/lib/templates/consularc.tt +9 -0
- data/lib/templates/example.term.tt +21 -0
- data/lib/templates/example.yml.tt +16 -0
- data/spec/cli_spec.rb +194 -0
- data/spec/consular_spec.rb +30 -0
- data/spec/core_spec.rb +19 -0
- data/spec/dsl_spec.rb +76 -0
- data/spec/fixtures/bar.term +32 -0
- data/spec/fixtures/foo.yml +10 -0
- data/spec/spec_helper.rb +54 -0
- data/spec.watchr +67 -0
- metadata +172 -0
data/Gemfile
ADDED
data/Gemfile.lock
ADDED
@@ -0,0 +1,28 @@
|
|
1
|
+
PATH
|
2
|
+
remote: .
|
3
|
+
specs:
|
4
|
+
consular (1.0.0)
|
5
|
+
activesupport
|
6
|
+
thor
|
7
|
+
|
8
|
+
GEM
|
9
|
+
remote: http://rubygems.org/
|
10
|
+
specs:
|
11
|
+
activesupport (3.1.1)
|
12
|
+
multi_json (~> 1.0)
|
13
|
+
fakefs (0.3.1)
|
14
|
+
metaclass (0.0.1)
|
15
|
+
minitest (2.6.1)
|
16
|
+
mocha (0.10.0)
|
17
|
+
metaclass (~> 0.0.1)
|
18
|
+
multi_json (1.0.3)
|
19
|
+
thor (0.14.6)
|
20
|
+
|
21
|
+
PLATFORMS
|
22
|
+
ruby
|
23
|
+
|
24
|
+
DEPENDENCIES
|
25
|
+
consular!
|
26
|
+
fakefs
|
27
|
+
minitest
|
28
|
+
mocha
|
data/LICENSE
ADDED
@@ -0,0 +1,20 @@
|
|
1
|
+
Copyright (c) 2011 Arthur Chiu
|
2
|
+
|
3
|
+
Permission is hereby granted, free of charge, to any person obtaining
|
4
|
+
a copy of this software and associated documentation files (the
|
5
|
+
"Software"), to deal in the Software without restriction, including
|
6
|
+
without limitation the rights to use, copy, modify, merge, publish,
|
7
|
+
distribute, sublicense, and/or sell copies of the Software, and to
|
8
|
+
permit persons to whom the Software is furnished to do so, subject to
|
9
|
+
the following conditions:
|
10
|
+
|
11
|
+
The above copyright notice and this permission notice shall be
|
12
|
+
included in all copies or substantial portions of the Software.
|
13
|
+
|
14
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
|
15
|
+
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
16
|
+
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
|
17
|
+
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
|
18
|
+
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
|
19
|
+
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
|
20
|
+
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
data/README.md
ADDED
@@ -0,0 +1,437 @@
|
|
1
|
+
Terminitor
|
2
|
+
===========
|
3
|
+
|
4
|
+
Terminitor automates your development workflow setup. Less time setting up, more time getting things done.
|
5
|
+
|
6
|
+
Upgrading Terminitor from 0.4.1 and under
|
7
|
+
------------------------------------------
|
8
|
+
|
9
|
+
For those upgrading from Terminitor 0.4.1, please run:
|
10
|
+
|
11
|
+
$ terminitor update
|
12
|
+
|
13
|
+
This will move your terminitor files to the new directory located at .config/terminitor
|
14
|
+
|
15
|
+
Installation
|
16
|
+
------------
|
17
|
+
|
18
|
+
$ gem install terminitor
|
19
|
+
$ terminitor init
|
20
|
+
|
21
|
+
Development Setup
|
22
|
+
---------------------
|
23
|
+
|
24
|
+
To begin development on Terminitor, run bundler:
|
25
|
+
|
26
|
+
$ gem install bundler
|
27
|
+
$ bundle install
|
28
|
+
|
29
|
+
The test suite uses ([Riot](https://www.github.com/thumblemonks/riot/)).
|
30
|
+
to run the test run:
|
31
|
+
|
32
|
+
$ rake test
|
33
|
+
|
34
|
+
or use watchr:
|
35
|
+
|
36
|
+
$ watchr test.watchr
|
37
|
+
|
38
|
+
or if you have terminitor installed,
|
39
|
+
|
40
|
+
$ terminitor fetch achiu terminitor
|
41
|
+
|
42
|
+
this will git clone the repo and bundle install.
|
43
|
+
|
44
|
+
Usage
|
45
|
+
-------
|
46
|
+
|
47
|
+
### Creating Local Projects ###
|
48
|
+
|
49
|
+
Using terminitor is quite easy. To define or edit a project file, simply invoke the command:
|
50
|
+
|
51
|
+
$ terminitor edit foo
|
52
|
+
|
53
|
+
This will open your default editor (set through the $TERM_EDITOR or $EDITOR variable in BASH) and you can proceed to define the commands for that project with the following syntaxes:
|
54
|
+
|
55
|
+
#### YAML Syntax ( Legacy ) ####
|
56
|
+
|
57
|
+
# ~/.config/terminitor/foo.yml
|
58
|
+
# you can make as many tabs as you wish...
|
59
|
+
# tab names are actually arbitrary at this point too.
|
60
|
+
---
|
61
|
+
- tab1:
|
62
|
+
- cd ~/foo/bar
|
63
|
+
- gitx
|
64
|
+
- tab2:
|
65
|
+
- mysql -u root)
|
66
|
+
- use test;
|
67
|
+
- show tables;
|
68
|
+
- tab3: echo "hello world"
|
69
|
+
- tab4: cd ~/baz/ && git pull
|
70
|
+
- tab5:
|
71
|
+
- cd ~/foo/project
|
72
|
+
- autotest
|
73
|
+
|
74
|
+
Simply define each tab and declare the commands. Note that the session for each tab is maintained, so you just declare actions here as
|
75
|
+
you would manually type in the terminal. Note that the title for each tab(namely tab1, tab2) are arbitrary, and can be named whatever you want.
|
76
|
+
They are simply placeholders for the time being for upcoming features.
|
77
|
+
|
78
|
+
To use the legacy syntax, you can invoke it with terminitor like so:
|
79
|
+
|
80
|
+
$ terminitor edit foo --syntax yml
|
81
|
+
|
82
|
+
It is recommended that you move over to the newer Ruby DSL Syntax as it
|
83
|
+
provides more robust features, however terminitor will still support the older
|
84
|
+
YAML syntax.
|
85
|
+
|
86
|
+
|
87
|
+
#### Ruby DSL Syntax ####
|
88
|
+
|
89
|
+
````ruby
|
90
|
+
setup 'echo "setup"' # code to run during setup
|
91
|
+
|
92
|
+
# open a tab in current window with these commands
|
93
|
+
tab "echo 'default'", "echo 'default tab'"
|
94
|
+
|
95
|
+
window do
|
96
|
+
before { run 'cd /path' } # run this command before each command.
|
97
|
+
|
98
|
+
run 'padrino start' # run in new window
|
99
|
+
|
100
|
+
tab "echo 'first tab'", "echo 'of window'" # create a new tab in window and run it.
|
101
|
+
tab "named tab" do
|
102
|
+
run "echo 'named tab'"
|
103
|
+
run "ls"
|
104
|
+
end
|
105
|
+
end
|
106
|
+
````
|
107
|
+
|
108
|
+
The newer Ruby DSL syntax allows for more complicated behavior such as window creation as well as setup blocks that can be executed prior loading a project.
|
109
|
+
|
110
|
+
##### Tabs #####
|
111
|
+
|
112
|
+
to create tabs, we can simply invoke the tab command with either the command arguments like:
|
113
|
+
|
114
|
+
````ruby
|
115
|
+
tab "echo 'hi'", "gitx"
|
116
|
+
````
|
117
|
+
|
118
|
+
or even pass it a block:
|
119
|
+
|
120
|
+
````ruby
|
121
|
+
tab do
|
122
|
+
run "echo 'hi'"
|
123
|
+
run "mate ."
|
124
|
+
end
|
125
|
+
````
|
126
|
+
|
127
|
+
##### Windows #####
|
128
|
+
|
129
|
+
to create windows, we can simply invoke the window command with a block containing additional commands like:
|
130
|
+
|
131
|
+
````ruby
|
132
|
+
window do
|
133
|
+
|
134
|
+
run "whoami" # Runs the command in the current window.
|
135
|
+
|
136
|
+
tab "echo 'hi'" # Creates another tab
|
137
|
+
tab "mate ." # And another
|
138
|
+
tab do # Last hoorah
|
139
|
+
run "open http://www.google.com"
|
140
|
+
end
|
141
|
+
end
|
142
|
+
````
|
143
|
+
|
144
|
+
##### Before #####
|
145
|
+
|
146
|
+
Sometimes you'll want to create a few commands that you want to run in each tab instance. You can do that with 'before':
|
147
|
+
|
148
|
+
````ruby
|
149
|
+
before { run "cd /path" } # execute this command before other commands in the default window
|
150
|
+
run "whoami"
|
151
|
+
tab 'uptime'
|
152
|
+
|
153
|
+
# In this instance, "cd /path" wil be executed in the default window before 'whoami'
|
154
|
+
# and also in the tab before 'uptime'.
|
155
|
+
# You can also use this inside a specific window context:
|
156
|
+
|
157
|
+
window do
|
158
|
+
before 'cd /tmp'
|
159
|
+
run 'watchr test.watchr' # "cd /tmp" first than run watchr
|
160
|
+
|
161
|
+
tab do
|
162
|
+
run 'padrino start' # "cd /tmp" is ran beforehand and then padrino start is executed
|
163
|
+
end
|
164
|
+
end
|
165
|
+
````
|
166
|
+
|
167
|
+
|
168
|
+
|
169
|
+
##### Setup #####
|
170
|
+
|
171
|
+
The setup block allows you to store commands that can be ran specifically before a project and can be defined with:
|
172
|
+
|
173
|
+
the command arguments:
|
174
|
+
|
175
|
+
````ruby
|
176
|
+
setup "bundle install", "gitx"
|
177
|
+
````
|
178
|
+
|
179
|
+
or with a block:
|
180
|
+
|
181
|
+
````ruby
|
182
|
+
setup do
|
183
|
+
run "echo 'hi'"
|
184
|
+
run "bundle install"
|
185
|
+
run 'git remote add upstream git://github.com/achiu/terminitor.git'
|
186
|
+
end
|
187
|
+
````
|
188
|
+
|
189
|
+
|
190
|
+
Once defined, you can invoke your projects setup with:
|
191
|
+
|
192
|
+
terminitor setup my_project
|
193
|
+
|
194
|
+
##### Settings #####
|
195
|
+
_currently only available for Mac OSX Terminal_
|
196
|
+
|
197
|
+
You can also set settings on each of your tabs and windows. for example, this is possible:
|
198
|
+
|
199
|
+
Open a tab with terminal settings "Grass"
|
200
|
+
|
201
|
+
````ruby
|
202
|
+
tab :name => "named tab", :settings => "Grass" do
|
203
|
+
run "echo 'named tab'"
|
204
|
+
run "ls"
|
205
|
+
end
|
206
|
+
````
|
207
|
+
|
208
|
+
This will create a tab with a title of 'named tab' using Terminals 'Grass' setting.
|
209
|
+
|
210
|
+
|
211
|
+
How about a window with a specific size:
|
212
|
+
|
213
|
+
````ruby
|
214
|
+
window :bounds => [10,20,300,200] do
|
215
|
+
|
216
|
+
end
|
217
|
+
````
|
218
|
+
|
219
|
+
Currently, the following options are available:
|
220
|
+
|
221
|
+
__tabs__
|
222
|
+
|
223
|
+
* :settings - [String] Set the tab to terminal settings
|
224
|
+
* :selected - [Boolean] Sets whether the tab is active
|
225
|
+
* :miniaturized - [Boolean] Sets whether its miniaturized
|
226
|
+
* :visible - [Boolean] Sets whether its visible
|
227
|
+
|
228
|
+
|
229
|
+
__windows__
|
230
|
+
|
231
|
+
* :bounds - [Array] Sets the bounds
|
232
|
+
* :miniaturized - [Boolean] Sets whether its miniaturized
|
233
|
+
* :visible - [Boolean] Sets whether its visible
|
234
|
+
|
235
|
+
### Running Terminitor Projects ###
|
236
|
+
|
237
|
+
Once the project file has been declared to your satisfaction, simply execute any project defined in the `~/.config/terminitor` directory with:
|
238
|
+
|
239
|
+
$ terminitor start foo
|
240
|
+
|
241
|
+
This will execute the steps and create the tabs defined and run the various options as expected. That's it. Create as many project files with as many tabs
|
242
|
+
as you would like and automate your workflow.
|
243
|
+
|
244
|
+
### Removing Terminitor Projects ###
|
245
|
+
|
246
|
+
If you no longer need a particular project, you can easily remove the terminitor file for the project:
|
247
|
+
|
248
|
+
$ terminitor delete foo
|
249
|
+
|
250
|
+
to remove a legacy yml syntax file you can run:
|
251
|
+
|
252
|
+
$ terminitor delete foo -s=yml
|
253
|
+
|
254
|
+
|
255
|
+
### Listing Terminitor Projects ###
|
256
|
+
|
257
|
+
You can also see a full list of available projects with:
|
258
|
+
|
259
|
+
$ terminitor list
|
260
|
+
|
261
|
+
This will print out the available project files that you can execute. The list also returns whatever text you have in the first comment of each terminitor script.
|
262
|
+
|
263
|
+
### Creating Termfile for Repo ###
|
264
|
+
|
265
|
+
In addition to creating 'local' projects which can run on your computer (and are stored in your home directory), we also
|
266
|
+
optionally allow you to create a `Termfile` within any directory and then you can execute this any time to setup the
|
267
|
+
environment for that particular project source.
|
268
|
+
|
269
|
+
For example, let's say I am in `/code/my/foo/project` directory which is
|
270
|
+
a Sinatra application. This application might have a `Gemfile` which includes all dependencies. You can also generate a `Termfile`
|
271
|
+
which contains the ideal development setup for OSX. To generate this file, invoke:
|
272
|
+
|
273
|
+
$ terminitor create
|
274
|
+
|
275
|
+
This will generate a 'Termfile' in the current project directory and open the file to be edited in the default text editor. The format
|
276
|
+
of the file is using the new Ruby DSL as described above in the previous section. You should *note* that the project directory is automatically
|
277
|
+
the working directory for each tab so you can just say `mate .` and the project directory containing the `Termfile` will open.
|
278
|
+
|
279
|
+
Now, when you or another developer clones a project, you could simply:
|
280
|
+
|
281
|
+
$ git clone git://path/to/my/foo/project.git
|
282
|
+
$ cd project
|
283
|
+
$ terminitor setup
|
284
|
+
$ terminitor start
|
285
|
+
|
286
|
+
This would clone the project repo, and then install all dependencies and then launch the ideal development environment for the project. Clearly
|
287
|
+
this makes assumptions about the user's system setup right now, but we have some ideas on how to make this work more effectively on
|
288
|
+
different configurations in the future.
|
289
|
+
|
290
|
+
In addition, you are in the project folder and you wish to remove the Termfile, you can invoke the command:
|
291
|
+
|
292
|
+
$ terminitor delete
|
293
|
+
|
294
|
+
This will clear the `Termfile` for the particular project.
|
295
|
+
|
296
|
+
### Capturing Terminal Settings with Terminitor ###
|
297
|
+
_Currently Mac OSX Terminal only_
|
298
|
+
Terminitor has the ability to also capture your terminal setup and settings simply with:
|
299
|
+
|
300
|
+
$ terminitor edit my_project --capture
|
301
|
+
|
302
|
+
this will open up a new terminitor project with the captured settings for you to continuing modifying as you see fit.
|
303
|
+
|
304
|
+
|
305
|
+
### Fetching Github Projects with Terminitor ###
|
306
|
+
|
307
|
+
Terminitor can also fetch code repositories off Github. This will have terminitor clone the repo into the current directory:
|
308
|
+
|
309
|
+
$ terminitor fetch achiu terminitor
|
310
|
+
|
311
|
+
After the repo has been fetched, terminitor will go ahead and run the setup block from the Termfile included in the repository. In the event you wouldn't want the setup block to be executed, simply set setup to false:
|
312
|
+
|
313
|
+
$ terminitor fetch achiu terminitor --setup=false
|
314
|
+
|
315
|
+
Some notes. Terminitor's fetch command is dependent on the ([github-gem](http://github.com/defunkt/github-gem)) at the current moment. It will try to fetch the repository with read/write access first if you have rights, if not, it will default to git read only. Happy fetching!
|
316
|
+
|
317
|
+
|
318
|
+
Cores
|
319
|
+
-----
|
320
|
+
|
321
|
+
Cores allow Terminitor to operate on a variety of platforms. They abstract the general behavior that terminitor needs to run the commands. Each core would inherit from an ([AbstractCore](http://github.com/achiu/terminitor/blob/master/lib/terminitor/abstract_core.rb)) and define the needed methods. At the moment the following Cores are supported:
|
322
|
+
|
323
|
+
* MacCore - Mac OS X Terminal
|
324
|
+
* KonsoleCore - KDE Konsole
|
325
|
+
* TerminatorCore - [Terminator](http://www.tenshu.net/terminator/)
|
326
|
+
* ITermCore - Mac OS X iTerm
|
327
|
+
|
328
|
+
Feel free to contribute more cores so that Terminitor can support your terminal of choice :)
|
329
|
+
|
330
|
+
|
331
|
+
Limitations
|
332
|
+
-----------
|
333
|
+
|
334
|
+
#### MacCore ####
|
335
|
+
|
336
|
+
Right now the Mac OS X Terminal tabs are created by invoking keystrokes which means there are limitations with the terminal being in
|
337
|
+
focus during execution of these commands. Obviously the long term goal is to solve this issue as well but in all honesty, this solution works well enough most of the time.
|
338
|
+
|
339
|
+
|
340
|
+
#### ITermCore ####
|
341
|
+
|
342
|
+
Currently the iTerm Core only provides basic functionality such as opening tabs, windows, and executing commands within them. It is also possible to split tabs into panes. The capture
|
343
|
+
and settings functionality will be integrated soon.
|
344
|
+
|
345
|
+
Splitting tabs into panes works as follows:
|
346
|
+
|
347
|
+
tab do
|
348
|
+
pane "gitx" # first pane
|
349
|
+
pane do # second pane level => horizontal split
|
350
|
+
run "irb"
|
351
|
+
end
|
352
|
+
pane 'ls' # first pane level => vertical split
|
353
|
+
end
|
354
|
+
|
355
|
+
should result into something like this:
|
356
|
+
|
357
|
+
# ###########################
|
358
|
+
# # # #
|
359
|
+
# # # #
|
360
|
+
# # 'gitx' # #
|
361
|
+
# # # #
|
362
|
+
# # # #
|
363
|
+
# ############## 'ls' #
|
364
|
+
# # # #
|
365
|
+
# # # #
|
366
|
+
# # 'irb' # #
|
367
|
+
# # # #
|
368
|
+
# # # #
|
369
|
+
# ###########################
|
370
|
+
|
371
|
+
It is not possible to split the second level panes (the horizontal
|
372
|
+
ones). Nevertheless you should be able to split tabs into any kind of pane pattern you wish
|
373
|
+
with this syntax.
|
374
|
+
|
375
|
+
|
376
|
+
#### Fetching ####
|
377
|
+
|
378
|
+
The fetch task only pulls off Github repositories at the moment. Later on, this functionality will be extended to non github repository.
|
379
|
+
|
380
|
+
|
381
|
+
#### Settings and Captures ####
|
382
|
+
|
383
|
+
This feature is currently only available in Mac OS X at the moment.
|
384
|
+
|
385
|
+
|
386
|
+
#### Terminator support ####
|
387
|
+
|
388
|
+
This feature currently requires the "xdotool" utility to be installed and in
|
389
|
+
the search path. The xdotool homepage is
|
390
|
+
http://www.semicomplete.com/blog/projects/xdotool/.
|
391
|
+
|
392
|
+
|
393
|
+
#### Windows suppport ####
|
394
|
+
|
395
|
+
Windows support is currently limited to plain cmd.exe. It is also
|
396
|
+
limited to only creating new windows, as cmd.exe does not support tabs.
|
397
|
+
|
398
|
+
|
399
|
+
Authors
|
400
|
+
-------
|
401
|
+
|
402
|
+
The core code was adapted before by Nathan Esquenazi and Thomas Shafer.
|
403
|
+
In September 2010, Arthur Chiu and Nathan Esquenazi gemified and released this to gemcutter.
|
404
|
+
|
405
|
+
Contributors
|
406
|
+
-------------
|
407
|
+
|
408
|
+
Thanks to the following people for their contributions so far:
|
409
|
+
|
410
|
+
* Pat George ([pcg79](https://github.com/pcg79)) for contributing a patch for when a project is not found.
|
411
|
+
* Tim Gossett ([[MrGossett](https://github.com/MrGossett)) for a patch to fix comment reading
|
412
|
+
* Flavio Castelli ([flavio](https://github.com/flavio)) for contributing Konsole(KDE) core.
|
413
|
+
* Alexey Kuleshov ([kulesa](https://github.com/kulesa)) for contributing the terminal settings and terminal settings capture functionality
|
414
|
+
* Arthur Gunn ([gunn](https://github.com/gunn)) for contributing a path to support tab syntax and load path.
|
415
|
+
* Elliot Winkler ([mcmire](https://github.com/mcmire)) for adding 1.8.6 compatiblity and ensuring tabs open in order and fixing named tabs
|
416
|
+
* Justin Hilemen ([bobthecow](https://github.com/bobthecow)) for fixing the list command to remove the term extensions.
|
417
|
+
* Dave Perrett ([recurser](https://github.com/recurser)) for adding basic iTerm support.
|
418
|
+
* Ilkka Laukkanen ([ilkka](https://github.com/achiu/terminitor/commits/master?author=ilkka)) for Terminator core and other fixes
|
419
|
+
* Elia Schito ([elia](https://github.com/achiu/terminitor/commits/master?author=elia)) for patch to allow usage of "&" for background operations
|
420
|
+
* Dotan J. Nahum ([jondot](https://github.com/jondot)) for adding windows(cmd.exe) support
|
421
|
+
* Kyriacos Souroullas ([kyriacos](https://github.com/kyriacos) for removing params to support generic commands
|
422
|
+
* Jerry Cheung ([jch](https://github.com/jch)) for adding ignore for emac backups
|
423
|
+
* Michael Klein ([LevelbossMike](https://github.com/LevelbossMike)) for adding iTerm Pane support
|
424
|
+
|
425
|
+
Acknowledgements
|
426
|
+
-----------------
|
427
|
+
|
428
|
+
|
429
|
+
|
430
|
+
The core terminal scripting code was initially developed by [Jeff Emminger](http://workingwithrails.com/person/2412-jeff-emminger) years ago. The original introduction was made on the [ELCTech Blog](http://blog.elctech.com/2008/01/16/script-terminal-with-terminit/) and a lot of that code was adapted from [Scripting the Terminal in Leopard](http://onrails.org/articles/2007/11/28/scripting-the-leopard-terminal).
|
431
|
+
|
432
|
+
This was a great start and made terminal automation easy. However, the repository died long ago, and we had continued using the code for a while.
|
433
|
+
Finally, we decided the time had come to release this code back to the world as a gem. Thanks to ELC for creating the original source for this project.
|
434
|
+
|
435
|
+
Also, we didn't take any code from [Project](http://github.com/joshnesbitt/project) by Josh but that project did inspire us to setup terminit
|
436
|
+
as a gem. Basically, project is a great gem but there were a couple issues with the fact that the terminal doesn't save the session state in some cases.
|
437
|
+
I had already been using terminit for years so we decided to package this up for easy use.
|
data/Rakefile
ADDED
data/Termfile
ADDED
data/bin/consular
ADDED
@@ -0,0 +1,13 @@
|
|
1
|
+
#!/usr/bin/env ruby
|
2
|
+
require File.expand_path('../../lib/consular',__FILE__)
|
3
|
+
|
4
|
+
rc = File.join(ENV['HOME'], '.consularc')
|
5
|
+
|
6
|
+
# Execute the configuration in our consularc
|
7
|
+
# if it exists.
|
8
|
+
#
|
9
|
+
if File.exists?(rc)
|
10
|
+
instance_eval File.read(rc), __FILE__, __LINE__
|
11
|
+
end
|
12
|
+
|
13
|
+
Consular::CLI.start(ARGV)
|
data/consular.gemspec
ADDED
@@ -0,0 +1,40 @@
|
|
1
|
+
# -*- encoding: utf-8 -*-
|
2
|
+
$:.push File.expand_path("../lib", __FILE__)
|
3
|
+
require "consular/version"
|
4
|
+
|
5
|
+
Gem::Specification.new do |s|
|
6
|
+
s.name = "consular"
|
7
|
+
s.version = Consular::VERSION
|
8
|
+
s.authors = ["Arthur Chiu"]
|
9
|
+
s.email = ["mr.arthur.chiu@gmail.com"]
|
10
|
+
s.homepage = "http://www.github.com/achiu/consular"
|
11
|
+
s.summary = %q{Quickly setup your terminal windows for your projects}
|
12
|
+
s.description = %q{Terminal Automation to get you on your projects quickly}
|
13
|
+
|
14
|
+
s.rubyforge_project = "consular"
|
15
|
+
|
16
|
+
s.files = `git ls-files`.split("\n")
|
17
|
+
s.test_files = `git ls-files -- {test,spec,features}/*`.split("\n")
|
18
|
+
s.executables = `git ls-files -- bin/*`.split("\n").map{ |f| File.basename(f) }
|
19
|
+
s.require_paths = ["lib"]
|
20
|
+
|
21
|
+
s.add_dependency 'thor'
|
22
|
+
s.add_dependency 'activesupport'
|
23
|
+
s.add_development_dependency 'minitest'
|
24
|
+
s.add_development_dependency 'mocha'
|
25
|
+
s.add_development_dependency 'fakefs'
|
26
|
+
|
27
|
+
s.post_install_message = %q{********************************************************************************
|
28
|
+
|
29
|
+
Consular has been installed! Please run:
|
30
|
+
|
31
|
+
consular init
|
32
|
+
|
33
|
+
This will create a directory at ~/.config/consular which will hold all your global scripts.
|
34
|
+
Also a .consularc file will be generated in your HOME directory which you can further configure
|
35
|
+
Consular.
|
36
|
+
|
37
|
+
********************************************************************************
|
38
|
+
}
|
39
|
+
|
40
|
+
end
|