Example 1.2: Set user name to user@domain.com
- $ kamaki set account user@domain.com
+ $ kamaki set account store.user@domain.com
Shell vs one-command
--------------------
config : Configuration commands
flavor : Compute/Cyclades API flavor commands
history: Command history
- image : Compute/Cyclades or Glance API image commands
+ image : Compute/Cyclades or Plankton API image commands
network: Compute/Cyclades API network commands
server : Compute/Cyclades API server commands
store : Pithos+ storage commands
Interactive shell
-----------------
-Kamaki interactive shell is details in this section
+Kamaki interactive shell is detailed in this section
Command Contexts
^^^^^^^^^^^^^^^^
[server]:/flavor list
...
- 20. AFLAVOR
+ 43 AFLAVOR
SNF:disk_template: drbd
cpu : 4
disk : 10
- id : 43
ram : 2048
[server]:/image list
[server]:create 'my debian' 43 6aa6eafd-dccb-67fe2bdde87e
...
-An other example (4.3.2) showcases how to acquire and modify configuration settings from a different context. In this scenario, the user token expires at server side while the user is working. When that happens, the system responds with an *(401) UNAUTHORIZED* message. The user can acquires a new token (with a browser) which has to be set to kamaki.
+An other example (4.3.2) showcases how to acquire and modify configuration settings from a different context. In this scenario, the user token expires at server side while the user is working. When that happens, the system responds with an *(401) UNAUTHORIZED* message. The user can acquire a new token (with a browser) which has to be set to kamaki.
.. code-block:: console
:emphasize-lines: 1
1. pithos (10MB, 2 objects)
2. trash (0B, 0 objects)
+.. note:: actual kamaki error messages are more helpful and descriptive.
+
The following example compares some equivalent calls that run *astakos-authenticate* after a *store-list* 401 failure.
.. code-block:: console
2. pithos (0B, 0 objects)
3. trash (2MB, 1 objects)
-.. warning:: In some cases, the config setting updates are not immediately effective. If that is the case, they will be after the next command run, whatever that command is.
-
Using history
^^^^^^^^^^^^^
Permanent history is implemented as a command group and is common to both the one-command and shell interfaces. In specific, every syntactically correct command is appended in a history file (configured as *history.file* in settings, see `setup section <setup.html>`_ for details). Commands executed in one-command mode are mixed with the ones run in kamaki shell (also see :ref:`using-history-ref` section on this guide).
+Scripting
+^^^^^^^^^
+
+Since version 6.2, the history-run feature allows the sequential execution of previously run kamaki commands in kamaki shell.
+
+The following kamaki sequence copies and downloads a file from mycontainer1, uploads it to mycontainer2, then undo the proccess and repeats it with history-run
+
+.. code-block:: console
+ :emphasize-lines: 1,12,19,32
+
+ * Download mycontainer1:myfile and upload it to mycontainer2:myfile
+ [kamaki]: store
+
+ [store]: copy mycontainer1:somefile mycontainer1:myfile
+
+ [store]: download mycontainer1:myfile mylocalfile
+ Download completed
+
+ [store]: upload mylocalfile mycontainer2:myfile
+ Upload completed
+
+ * undo the process *
+ [store]: !rm mylocalfile
+
+ [store]: delete mycontainer1:myfile
+
+ [store]: delete mycontainer2:myfile
+
+ * check history entries *
+ [store]: exit
+
+ [kamaki]: history
+
+ [history]: show
+ 1. store
+ 2. store copy mycontainer1:somefile mycontainer1:myfile
+ 3. store download mycontainer1:myfile mylocalfile
+ 4. store upload mylocalfile mycontainer2:myfile
+ 5. history
+ 6. history show
+
+ *repeat the process *
+ [history]: run 2-4
+ store copy mycontainer1:somefile mycontainer1:myfile
+ store download mycontainer1:myfile mylocalfile
+ Download completed
+ store upload mylocalfile mycontainer2:myfile
+ Upload completed
+
+The above strategy is still very primitive. Users are advised to take advantage of their os shell scripting capabilities and combine them with kamaki one-command for powerful scripting. Still, the history-run functionality might prove handy for kamaki shell users.
+
Tab completion
^^^^^^^^^^^^^^
[kamaki]:!ls -al
total 16
- drwxrwxr-x 2 saxtouri saxtouri 4096 Nov 27 16:47 .
- drwxrwxr-x 7 saxtouri saxtouri 4096 Nov 27 16:47 ..
- -rw-rw-r-- 1 saxtouri saxtouri 8063 Jun 28 14:48 kamaki-logo.png
+ drwxrwxr-x 2 username username 4096 Nov 27 16:47 .
+ drwxrwxr-x 7 username username 4096 Nov 27 16:47 ..
+ -rw-rw-r-- 1 username username 8063 Jun 28 14:48 kamaki-logo.png
[kamaki]:shell cp kamaki-logo.png logo-copy.png
[kamaki]:shell ls -al
total 24
- drwxrwxr-x 2 saxtouri saxtouri 4096 Nov 27 16:47 .
- drwxrwxr-x 7 saxtouri saxtouri 4096 Nov 27 16:47 ..
- -rw-rw-r-- 1 saxtouri saxtouri 8063 Jun 28 14:48 kamaki-logo.png
- -rw-rw-r-- 1 saxtouri saxtouri 8063 Jun 28 14:48 logo-copy.png
+ drwxrwxr-x 2 username username 4096 Nov 27 16:47 .
+ drwxrwxr-x 7 username username 4096 Nov 27 16:47 ..
+ -rw-rw-r-- 1 username username 8063 Jun 28 14:48 kamaki-logo.png
+ -rw-rw-r-- 1 username username 8063 Jun 28 14:48 logo-copy.png
-Kamaki shell commits command strings to the outside shell and prints the results, without interacting with it. After a command is finished, kamaki shell returns to its initial state, which involves the current directory, as show in example 4.7.2 .
+Kamaki shell commits command strings to the outside shell and prints the results, without interacting with it. After a command is finished, kamaki shell returns to its initial state, which involves the current directory, as show in example 4.8.2 .
.. code-block:: console
:emphasize-lines: 1
- Example 4.7.2: Attempt (and fail) to change working directory
+ Example 4.8.2: Attempt (and fail) to change working directory
[kamaki]:!pwd
projects / kamaki / blobdiff