I tried at first setting the file’s encoding system with the tag “-*-coding: utf-8 -*-”, though it seemed not sufficient. The raw characters remained there and I soon grew tired of having to type in: “utf-8” at the prompt to select the encoding every time I needed to save the file.

Today searching the manual found here one easy cure on the command “recode-region” which allows to convert the text that was decoded with the wrong coding system.

Really all it took after marking the whole buffer (C-x h) was doing: “M-x recode-region RET” “Text was was really in: utf-8” “But was interpreted as: raw-text”

That was it!, the drag is over, I’m back to storing notes quickly doing just C-c r and C-c C-x with the worthy remember mode.

Although “the soft newlines used for line wrapping will not show up when the text is yanked or saved to disk”, they will remain if, say, I had carelessly pasted it directly into a gmail form to save for later reuse there.

My way to remove those artificially-inserted line breaks, is running this oneliner on the text region.

sed -ne '1h;1!H;${;g;s#\n\([^\n]\)# \1#g;p}' | sed -e 's#^[ \t]*\(.*\)$#\1#g'

(The first sed command tells to put a space and remove the line break. using the multiline search and replace method
The second just gets rid of the leading white space at the beginning of line)

UPDATE: seems that I spoke too soon. Asking about the present working directory, formerly “(let ((a (shell-command-to-string “pwd | tr -d ‘\\n’”)))”, didn’t actually work when having opened shells of different servers via Tramp.
The correction below (less elegant) depends on the shell buffer being created/renamed with an identifiable name -which could be the hostname or whatever consistent nomenclature we choose-.
Anyway, until figuring a better way, this does the job of inserting the right parameters into each shell:

(defun my-heredoc-sql-invocation-from-shell ()
"Insert the appropiate parameters to run a heredoc mysql query depending on which shell I'm in"
  (interactive)
  (let ((a (buffer-name (window-buffer (minibuffer-selected-window))))
        (b nil))
    (cond ((string-match "serverA" a)
           (setq b "mysql -uroot mainDbToHitAt_A--password=`cat /etc/security/mysqlpassword` -t -vv <<\\!"))
          ((string-match "serverB" a)
           (setq b "mysql -ualpha mainDbToHitAt_B --password=`cat /etc/security/mysqlpassword` -t -vv <<\\!"))
          ((string-match "serverC" a)
           (setq b "mysql -uroot mainDbToHitAt_C  -t <<\\!")))
    (insert b)))

;; key shortcut to bind it to
(global-set-key (kbd "C-S-<f11>")  'my-heredoc-sql-invocation-from-shell)

Although a handy way to use every now and then, I still felt this sort of limited since the query to be passed in the “-e” argument must go inside a single line. In search of  a better alternative I was pleased to figure instead that it’s possible to combine heredoc sintaxis with the sql execution in the command line. Heredoc is a mechanism to break text into multiple lines, just as a file would be treated, after the “<<” sign, the parser says: “here follows a document” which gets wrapped inside the pair of whatever text delimeters we choose. The obvious convenience is that without having to create a file we could easily run multiline queries -which read more naturally with line breaks and indentation- in the same way we would write them inside a file.

To quickly see what I’m talking about type

Now hit “Control D” and then, “Enter” to see the output directly thrown at your shell

To speed things up, since  I use the shell inside emacs, I bound the following to C-S f11 adding  what is below into my .emacs file:

Now in this case what I needed was a CSV file, for which I piped it to sed reeplacing tabs by commas doing:

or even more usefully:

find . -ctime +7  -ctime -21 # (older than 7 days but newer than three weeks ago)

There are simply 3 options of numeric arguments for time

1. +n –> More than ‘n’ days ago.
2. -n –> Less than ‘n’ days ago.
3. n —> Exactly ‘n’ days ago.

1. Get the creation statement for the table to be recovered

   cat your_entire_backup_file.sql | sed -ne '/Table structure for table `your_table`/,/-- Dump/p' > table_creation.sql
   

2. Get the data

   cat your_entire_backup_file.sql | sed -ne '/INSERT INTO `your_table`/,/Table structure/p' > data_dump.sql
   

3. Join the two into a single file

   cat table_creation.sql data_dump.sql > data_for_single_table_to_copy
   

4. Optionally, in case you need to extract some rows only from that previous instance of the table, as it was my case with records deleted by mistake, you might want to create a temporary table from where to later perfom the selection of the desired rows. In order to do that, the table name should be altered from the creation and insertion statements:

   sed -i 's#your_table#your_temp_table#g' data_for_single_table_to_copy.sql
   

5. Now we are ready to create that temporary table with its data inside our database:

   mysql -u 'your_username -p your_database_name < 'your_path_to_the_file/data_for_single_table_to_copy.sql
   

6. Voila!, the table is there containing the information you needed. Now is up to you to extract and reinsert whatever you wanted inside the original table

Note: See that different parameters could be used to isolate and put together table creation and data parts in only one pass. Also the awk command might be used instead since, like sed, it permits collecting portions by matching from the beginning to the ending block of text. Just make sure you know the order of the table after the one you are picking.

awk '/Table structure for table `your_table`/,/Table structure for table `your_next_table`/{print}' your_entire_backup_file.sql > data_for_single_table_to_copy.sql

In case the table to extract happens to be the last one (which again, you could just know with a mysq “show tables” command, modify the last part of the regexp to match it accordingly.

Here are some neat examples for backing up (or mirroring) sites with ssh I don’t want to miss:

There’s a really easy way to make a remote directory be an exact match of a local directory via an ssh connection. And that’s to use rsync to do the job. It’s smart and only sends enough data to sync the remote dir to the local one. Assuming that you have a local dir named master-copy and the remote system’s repository is in a directory named slave-copy you’d do:

rsync --rsh=ssh --delete -Cav master-copy/* user-name@remote.dom.tld:/path-to/slave-copy

That command will recursively sync everything found in master-copy to the remote. Any files found on the remote that aren’t in master-copy or one of its sub-dirs will be deleted from master-copy. Only changed or new files will be transferred to the remote.

to which another expert adds:

The rsync idea is good — but I for my part always try NOT to install any additional software not essentially required. Today, ssh is “a must” on most systems and you can go with the cpio approach I’ve mentioned.
I must admit the rsync thing is transferring less data if stuff is already on the target side, but this is not the case when running
source=/var/tmp ; target=/var/backup
cd $source ; find . -mtime -1 -type f -print | cpio -ocB | ssh -l username host-b "cd $target ; cpio -icBduml"
daily.

Another suggestion to copy the entire directory tree at /some/path to other.host via SSH is to do:

find /some/path -print | sort | cpio -o -Hnewc | ssh -C other.host "cpio -idvum"

Finally, there’s more to chew with this thorough example on how to mirror a site with rsync http://www.askapache.com/security/mirror-using-rsync-ssh.html