add (specific) quotation marks (before and after word)

[Duns]

In LibreWriter is automatic add this “ quotation marl before a word, and this other  ” after a work (they can change according to different languages).

It would be great if in other programs, such as Kate, you could do the same.

It is possible convert automatically, with autokey, " (before a word) in  “ and likewise " after a word in ”  ?

Thanks!

[Joe]

If you're OK at scripting, it's not too hard, but it's more than a few
lines of code, especially if it selects the word for you and can handle
more than one quoting style.

I'm going to assume the word in question is already in plain quotes. (If
it's not, it's actually easier.)

Before getting into this though: If you have a plain text file (you said
kate) with the quoted words already in it, this is a perfect application
for sed or awk. It will get all of them in a flash and if you build it
into a shell script, you could even select the quoting style as a
parameter. This would be way easier than picking through a file word by
word in AutoKey. It's also way less code. And, it's not very hard to
turn a script like this into a GUI application if necessary. I do a lot
of things like this.

E.g. I have a bash script that encrypts a file doing some extra things
as well. I added it to my system menu in KDE and then added it to the
list of applications that my file manager offers when I right click on a
file icon. To encrypt a file, all I have to do is right click on it and
then click on encrypt and I'm done. Once you see how the process works,
it's very easy to do.

In AutoKey:

Highlight the word including the quotes manually. This is annoying
because the quotes aren't word characters so you can't just double click
on the word to select it.
    (we'll come back to that later.)

import time

left_quote = the unicode character for the left quote of your chosen
language
right_quote = the unicode character for the right quote of your chosen
language

quoted_word = clipboard.get_selection()
time.sleep(0.1)
quoted_word[0] = left_quote
quoted_word[-1] = right_quote
clipboard.fill_clipboard(quoted_word)
time.sleep(0.1)
keyboard.send_keys("<ctrl>+v")

If you want to get fancy, you could have a dictionary (Python
associative array) of quotes for various languages and have the proper
entry selected using an AutoKey global variable. You could then have a
second script that sets the language mode in a global variable and have
the above script get the language mode using that AutoKey global variable.

Now, if you want to make it more efficient to use, have your script help
with the selecting.

The problem with this is that it appears to be application window
specific. I just figured out the required key sequences in Thunderbird
(my email client) and in kate and they aren't the same (at least the way
I did it), so you either have to have separate scripts for each
application (with window filters or separate hotkeys) or use the
window.get_active_class() and or window.get_active_title() to find out
what kind of application you're talking to and use that to choose the
appropriate key sequence to use.

Here's one for kate (assuming that the text cursor is somewhere in the
middle of the word. All done with keyboard.send_keys() calls.)

<ctrl>+<left>
<left>
<ctrl>+<shift>+<right>
<ctrl>+<shift>+<right>
<ctrl>+<shift>+<right>

English:
Go to begin of word (and clear any preexisting selection) (text cursor
must start out *past* the first character in the word or this will
overshoot to the left)
Go left to be in front of the leading quote
Select word to right three times to select  the leading quote, the word
itself, and the trailing quote

You should probably put a time.sleep(0.1) after each of these to start
with. Once it works, you can try commenting out some of the delays until
it breaks and you see where they're actually needed.

Joe

> --
> You received this message because you are subscribed to the Google
> Groups "autokey-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to autokey-user...@googlegroups.com
> <mailto:autokey-user...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/autokey-users/8213dd28-a2da-41ef-8a18-20232d60b246n%40googlegroups.com
> <https://groups.google.com/d/msgid/autokey-users/8213dd28-a2da-41ef-8a18-20232d60b246n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Duns]

Uhm... Thank youy, Joe, but this way seems too complicated to me (I'm not an expert developer, sorry).

It is easier for me a hotkeys use (such as ctrl+q for beginning quote, and ctrl+shift+q for ending quote).

However what you said «If you want to get fancy, you could have a dictionary (Python

associative array) of quotes for various languages and have the proper
entry selected using an AutoKey global variable. You could then have a
second script that sets the language mode in a global variable and have

the above script get the language mode using that AutoKey global variable.»

could be very interesting: where can I find some easy explanation? I don't need any kind of quotes but Italian....

[zahid saleem]

From: ijaz store, Pakistan. Dear businessman: You good self sells after all buying from somewhere? Can you buy from us? Do you want to check our prices? Whatsapp 00923150085681, zahidsal...@gmail.com, Apparel, CPU, Clothes, dry fruits, FMCG, food items, fruits, furniture, garments, groceries,  herbs, keyboards, laptops, mouse, monitors, perfumes, printers, sneakers, spare parts for Suzuki, Toyota, Honda cars, tablets, Toys for babies, kids, children for amusement, playing, education. etc. WHAT REWARD YOU PLEASE WANT. Registered office address: Ijaz store / corporation, Rawalpindi 46000, Pakistan, Whatsapp; 0092 315 0085681, Email; zahidsal...@gmail.com, National tax No. 7622921-2, Sales tax No. 3277876146819, (supplier, wholesellers, Government Contractors / builders /constructors) – PEC Licensed                                                                                                                                                                                                                

Warehouse address: SAME

To unsubscribe from this group and stop receiving emails from it, send an email to autokey-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/autokey-users/56f5c35a-7907-4b6a-b9f1-4e25f64ee138n%40googlegroups.com.

[Joe]

Then, just go with the first solution - almost all the code is in the
previous email.

or just actually make phrases just for left and right quotes.

I still think sed is your best bet.

sed is tricky, but wonderfully powerful and blindingly fast.

sed -re 's/\"(.*)\"/\xXX\1\xYY/g' your-text-file.txt >
your-new-text-file.txt

See https://unicode-table.com/en/sets/quotation-marks/

and you convert the Unicode code points for the new quote characters to
hexadecimal and replace XX and YY above with the values so sed will be
happy.

You get the whole thing done in one line of code. You can make another
one for the quotes in each different language.

English:

Find all occurrences (that's what "g" says) of a double quote followed
by anything - .* - followed by another double quote on each line of the file

and grab everything between the two quotes - that's what the parentheses do

substitute (replace) (s) the whole thing with the new left quote
followed by whatever was between the two quotes - \1 - followed by the
new right quote.

The results gets written to a new file, so the original file is safe.

----

Dictionaries:

https://www.w3schools.com/python/python_dictionaries.asp

https://www.tutorialspoint.com/python/python_dictionary.htm

Something like: (I've never done this, so it might not work as is.)

quotes = {
  "English" : {
    "left_quote" : '"',
    "right_quote" : '"'
  },
  "Italian" : {
    "left_quote" : '"',
    "right_quote" : '"'
  },
  "Klingon" : {
    "left_quote" : '"',
    "right_quote" : '"'
  }
}

should work, once you replace the quote (") characters with the
appropriate Unicode characters for the other languages using \uxxx
notation or just pasting them into your code.

language = "Italian" ## this could in set by another script and
retrieved from an AutoKey global variable.
lq = quotes{language{"left_quote"}}
rq = quotes{language{"right_quote"}}

You would get that code working in the Python interpreter where
debugging and iteration is fast and easy and then build it into your
AutoKey script.

Jack and a few others on this list know a lot more Python than I do.

Joe

On 10/3/20 11:11 AM, Duns wrote:
> Uhm... Thank youy, Joe, but this way seems too complicated to me (I'm
> not an expert developer, sorry).

> It is easier for me a *hotkeys* use (such as ctrl+q for beginning

> https://groups.google.com/d/msgid/autokey-users/56f5c35a-7907-4b6a-b9f1-4e25f64ee138n%40googlegroups.com
> <https://groups.google.com/d/msgid/autokey-users/56f5c35a-7907-4b6a-b9f1-4e25f64ee138n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Johnny Rosenberg]

Just for the fun of it, I tried another solution, and it seems to work:

I triggered the " key to a script (maybe it's better to trigger something else, for instance Ctrl+", otherwise it's nearly impossible to type an actual ", for instance when programming). In the Set Abbreviation dialogue, I set the following:

☒ remove typed abbreviation

☐ Omit trigger character

☐ Ignore case of typed abbreviation

☒ Trigger when typed as part of a word

☒ Trigger immediately (don't require a trigger character)

This is not necessary if triggering to Ctrl+" or similar, of course.

Then, when a " is typed, a dialogue opens and you type your text there and then you hit ↵ (Enter). Your text is pasted with the quotation marks for your locale around it.

I only included a few locales and I didn't test what happens if my locale is not in the list, but feel free to add more and correct those I included, if they are wrong.

Here's my script:

import os

Locale=os.environ['LANG'][0:5]
QuotationMarks={
    "da_DK": {"Left":  "»", "Right":  "«"},
    "de_DE": {"Left":  "„", "Right":  "“"},
    "en_GB": {"Left":  "‘", "Right":  "’"},
    "en_US": {"Left":  "“", "Right":  "”"},
    "es_ES": {"Left":  "«", "Right":  "»"},
    "fr_FR": {"Left": "« ", "Right": " »"},
    "it_IT": {"Left":  "«", "Right":  "»"},
    "nb_NO": {"Left":  "«", "Right":  "»"},
    "nn_NO": {"Left":  "«", "Right":  "»"},
    "pl_PL": {"Left":  "„", "Right":  "”"},
    "pt_BR": {"Left":  "“", "Right":  "”"},
    "pt_PT": {"Left":  "«", "Right":  "»"},
    "sv_FI": {"Left":  "”", "Right":  "”"},
    "sv_SE": {"Left":  "”", "Right":  "”"}
}
LQuote=QuotationMarks.get(Locale).get("Left")
RQuote=QuotationMarks.get(Locale).get("Right")
OriginalClipboard=clipboard.get_clipboard()
retCode, sText=dialog.input_dialog(title="Quote",
                                   message="Text: ")
if retCode==0:
    clipboard.fill_clipboard(LQuote+sText+RQuote)
    keyboard.send_keys("<ctrl>+v")
    time.sleep(0.1)
clipboard.fill_clipboard(OriginalClipboard)

If only one locale is required, this much shorter script should work (adjust the values of LQuote and RQuote to your liking):

LQuote="«"
RQuote="»"

OriginalClipboard=clipboard.get_clipboard()
retCode, sText=dialog.input_dialog(title="Quote",
                                   message="Text: ")
if retCode==0:
    clipboard.fill_clipboard(LQuote+sText+RQuote)
    keyboard.send_keys("<ctrl>+v")
    time.sleep(0.1)
clipboard.fill_clipboard(OriginalClipboard)

If wrong things are pasted, try to increase the time value in time.sleep(0.1).

Kind regards

Johnny Rosenberg

To unsubscribe from this group and stop receiving emails from it, send an email to autokey-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/autokey-users/d84a1d06-3cbf-0d22-61d6-14d01e7d5b19%40main.nc.us.

[Duns]

Thank you, Joe and Johnny. The last solution is very easy. I wonder if there could be an ever simpler solution: something

like

text = clipboard.get_selection()
keyboard.send_key("<delete>")
keyboard.send_keys("“%s”" % text)

but as I have written it is not working (perhaps I should add something before and after “ and ” ) ...

[Little Girl]

Hey there,

I thought I'd take a stab at it. The following script removes the quotes from the selected text and wraps the selected text with curly quotes:

#Get the contents of the clipboard, remove the quotes from it, and save the resulting value to a variable:
target = clipboard.get_selection().replace("\"","")

#Surround the value of the variable with curly quotes and send the resulting value to the currently active window:
keyboard.send_keys("<ctrl>+<shift>+u201C%s<ctrl>+<shift>+u201D" % target)

[Little Girl]

Hey there,

Or, for those who prefer one change to the target at a time:

#Get the contents of the clipboard and save their value to a variable:
target = clipboard.get_selection()

#Remove the quotes from the value of the variable:
target = target.replace("\"","")

#Surround the value of the variable with curly quotes:
target = "<ctrl>+<shift>+u201C%s<ctrl>+<shift>+u201D" % target

#Send the value of the variable to the currently active window:
keyboard.send_keys(target)

[Joe]

Here's another article on Python dictionaries that just arrived in my inbox.

https://www.golinuxcloud.com/15-examples-to-use-python-dictionary-for-beginners/

Joe

[zahid saleem]

[Joe]

Interesting. I didn't think keyboard.send_keys() could deal with
Unicode. I guess this bypasses that limitation by not sending any actual
Unicode and letting the receiving application generate it.

Joe

On 10/4/20 11:37 PM, Little Girl wrote:
> Hey there,
>
> Or, for those who prefer one change to the target at a time:
>
> |
> #Get the contents of the clipboard and save their value to a variable:
> target =clipboard.get_selection()
>
> #Remove the quotes from the value of the variable:

> target =target.replace("\"","")

>
> #Surround the value of the variable with curly quotes:
> target ="<ctrl>+<shift>+u201C%s<ctrl>+<shift>+u201D"%target
>
> #Send the value of the variable to the currently active window:
> keyboard.send_keys(target)
> |
>

> --
> You received this message because you are subscribed to the Google
> Groups "autokey-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to autokey-user...@googlegroups.com
> <mailto:autokey-user...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/autokey-users/7c1cd831-6d72-4444-ac97-4187a81d6e59o%40googlegroups.com
> <https://groups.google.com/d/msgid/autokey-users/7c1cd831-6d72-4444-ac97-4187a81d6e59o%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Johnny Rosenberg]

Den sön 4 okt. 2020 kl 20:50 skrev Duns <dr.be...@gmail.com>:

Thank you, Joe and Johnny. The last solution is very easy. I wonder if there could be an ever simpler solution: something

like

text = clipboard.get_selection()
keyboard.send_key("<delete>")
keyboard.send_keys("“%s”" % text)

I thought you wanted to use those quotation marks on the fly when you typed, so maybe I misunderstood the problem. The solution above seems to assume that you first select your text before running the script. Of course you can let the script select it for you, but it will probably take some time if the text is long, and I guess that could be somewhat annoying.

Kind regards

Johnny Rosenberg

 

To view this discussion on the web visit https://groups.google.com/d/msgid/autokey-users/97e84ecc-492a-4538-987a-378483fc2c17n%40googlegroups.com.

[zahid saleem]

[Johnny Rosenberg]

Den ons 7 okt. 2020 kl 07:56 skrev zahid saleem <zahidsal...@gmail.com>:

From: ijaz store, Pakistan. Dear businessman: You good self sells after all buying from somewhere? Can you buy from us? Do you want to check our prices? Whatsapp 00923150085681, zahidsal...@gmail.com, Apparel, CPU, Clothes, dry fruits, FMCG, food items, fruits, furniture, garments, groceries,  herbs, keyboards, laptops, mouse, monitors, perfumes, printers, sneakers, spare parts for Suzuki, Toyota, Honda cars, tablets, Toys for babies, kids, children for amusement, playing, education. etc. WHAT REWARD YOU PLEASE WANT. Registered office address: Ijaz store / corporation, Rawalpindi 46000, Pakistan, Whatsapp; 0092 315 0085681, Email; zahidsal...@gmail.com, National tax No. 7622921-2, Sales tax No. 3277876146819, (supplier, wholesellers, Government Contractors / builders /constructors) – PEC Licensed                                                                                                                                                                                                                

Warehouse address: SAME    

Will someone please block this annoying user? If that is possible, that is.

Kind regards

Johnny Rosenberg

--
You received this message because you are subscribed to the Google Groups "autokey-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to autokey-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/autokey-users/CANNxEPuX0x2f5vpq4FSgR7dve%2BuNGZpx-hXjFd%3DBVhkQ0K1M%3DQ%40mail.gmail.com.

[Little Girl]

Yeah, it was quite a wrestle to figure out how to get around it, but you're right that this is a way to bypass that limitation. It's not perfect, though. As you can see, it's a bit awkward to do, and it also has limitations:

• If you want to insert the Unicode character inside of a string, it will display properly if it's at the beginning or in the middle of the string and is followed by a space or a plus sign. Note that the plus sign will not be displayed and is merely used as a way to display something other than a space immediately following a Unicode character.
• #If a Unicode character will be the last or only character you print, an additional key-press of one of a few specific keys (Ctrl, Enter, Shift, or Space) is required to get rid of the tooltip and replace it with the Unicode character. To avoid that necessity for user intervention, follow the Unicode character with either a space or a plus sign, either of which will not be rendered when the Unicode character is printed and are just used to satisfy the need for that additional key-press.
• You can't use keyboard.send_key() for these, because they're not single characters, so you must use keyboard.send_keys() to print these.
• You can go "shopping" for any of the Unicode on places like the https://unicode-table.com/en/ website, but must choose one that has only four characters in its Hex code.

Here are a few examples:

#Print a tooltip and replace it with a snowman if the user presses any of certain keys (Ctrl, Enter, Shift, or Space):
keyboard.send_keys("<ctrl>+<shift>+u+2603")
keyboard.send_keys("<ctrl>+<shift>+u2603")
#Print a snowman, but send an additional keypress (a plus, a space, Ctrl, Enter, or Shift) to avoid displaying a tooltip that requires user intervention:
keyboard.send_keys("<ctrl>+<shift>+u+2603+<right>")
keyboard.send_keys("<ctrl>+<shift>+u2603+<right>")
keyboard.send_keys("<ctrl>+<shift>+u2603+")
keyboard.send_keys("<ctrl>+<shift>+u+2603 ")
keyboard.send_keys("<ctrl>+<shift>+u+2603<ctrl>")
keyboard.send_keys("<ctrl>+<shift>+u+2603<enter>")
keyboard.send_keys("<ctrl>+<shift>+u+2603<shift>")
#Print a snowman with a period after it by sending a plus sign as an additional keypress to avoid displaying a tooltip that requires user intervention:
keyboard.send_keys("<ctrl>+<shift>+u+2603+.")

[Little Girl]

Johnny Rosenberg wrote:

Will someone please block this annoying user? If that is possible, that is.

I clicked the three dots to the right of each of his messages and clicked on the entry to report abuse so that Google will take care of it. You can do it, too. Probably the more of us who do it, the better.

[Johnny Rosenberg]

Yes, I know. I just thought that if it was possible to block it from the group, it would be more efficient. But yes, you're right, and I will do that too.

Kind regards

Johnny Rosenberg

--
You received this message because you are subscribed to the Google Groups "autokey-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to autokey-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/autokey-users/f8b4a5ec-fc33-41c2-a9fc-bc1ec8dab54do%40googlegroups.com.

[Little Girl]

Hey there,

Ah, probably not. People like that change their user accounts, so even if one gets blocked, the next one won't be until there's misbehavior.

[Little Girl]

Hey there,

Johnny Rosenberg wrote:

I thought you wanted to use those quotation marks on the fly when you typed, so maybe I misunderstood the problem. The solution above seems to assume that you first select your text before running the script. Of course you can let the script select it for you, but it will probably take some time if the text is long, and I guess that could be somewhat annoying.

I totally forgot to reply to this. I had thought about it when this thread first started. The problem with it is that the curly quotes are two different characters, so a simple search and replace of one character with another won't do. It would have to replace the first quote it comes across with one character and the next with another and then repeat that sequence over and over throughout the text with each pair of double-quote characters it encounters. That would assume that the currently active window contains nothing but complete quotes and would never start with just the closing quote of a pair. It would also assume that a lone double-quote character would never be used in any way other than as part of a pair surrounding quoted strings and would never appear as a single character for any other purpose. If none of that would be an issue, something like this should be doable.

[Little Girl]

Hey there,

And last, but not least, doing it on the fly would be complicated in that the script would have to figure out which of the characters it should replace the current double-quote character with based on what it sees in the text that came before the most recent double quote. To do that, it would probably have to search for occurrences of the curly-quote pairs and eliminate them, determine if there's a lone curly-quote remaining that needs a mate and add its mate, or convert the most recent double-quote into the first of the curly-quote characters. Before it does that, though, it should also check for any as-yet-unconverted double-quote characters that need to be converted to make the sequence consistent. This could get more and more complex as time goes by and it's starting to turn my brains to spaghetti. It doesn't help that I think linearly. Such a thing is probably a quick and effortless if statement for folks who don't.

[Joe]

God bless sed! This is what it was invented for. I see no obvious reason
to use AutoKey for this at all. One relatively simple regex in one line
of code any you're done.

It gets a little trickier if you want to support multiple quoting styles
because you have to deal with the shell trying to expand the sed command
tokens.

Joe

> --
> You received this message because you are subscribed to the Google
> Groups "autokey-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to autokey-user...@googlegroups.com
> <mailto:autokey-user...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/autokey-users/e3cbfb50-32aa-49d0-8baa-57d532bdf95do%40googlegroups.com
> <https://groups.google.com/d/msgid/autokey-users/e3cbfb50-32aa-49d0-8baa-57d532bdf95do%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Joe]

This is very nice. Your detailed examples are quite useful.

Joe

On 10/7/20 4:21 PM, Little Girl wrote:
> Yeah, it was quite a wrestle to figure out how to get around it, but
> you're right that this is a way to bypass that limitation. It's not
> perfect, though. As you can see, it's a bit awkward to do, and it also
> has limitations:
>

> * If you want to insert the Unicode character inside of a string, it

> will display properly if it's at the beginning or in the middle of
> the string and is followed by a space or a plus sign. Note that
> the plus sign will not be displayed and is merely used as a way to
> display something other than a space immediately following a
> Unicode character.

> * #If a Unicode character will be the last or only character you

> print, an additional key-press of one of a few specific keys
> (Ctrl, Enter, Shift, or Space) is required to get rid of the
> tooltip and replace it with the Unicode character. To avoid that
> necessity for user intervention, follow the Unicode character with
> either a space or a plus sign, either of which will not be
> rendered when the Unicode character is printed and are just used
> to satisfy the need for that additional key-press.

> * You can't use *keyboard.send_key()* for these, because they're not
> single characters, so you must use *keyboard.send_keys()* to print
> these.
> * You can go "shopping" for any of the Unicode on places like the

> https://unicode-table.com/en/ website, but must choose one that
> has only four characters in its Hex code.
>
> Here are a few examples:
> |
> #Print a tooltip and replace it with a snowman if the user presses any
> of certain keys (Ctrl, Enter, Shift, or Space):
> keyboard.send_keys("<ctrl>+<shift>+u+2603")
> keyboard.send_keys("<ctrl>+<shift>+u2603")
> #Print a snowman, but send an additional keypress (a plus, a space,
> Ctrl, Enter, or Shift) to avoid displaying a tooltip that requires
> user intervention:
> keyboard.send_keys("<ctrl>+<shift>+u+2603+<right>")
> keyboard.send_keys("<ctrl>+<shift>+u2603+<right>")
> keyboard.send_keys("<ctrl>+<shift>+u2603+")
> keyboard.send_keys("<ctrl>+<shift>+u+2603 ")
> keyboard.send_keys("<ctrl>+<shift>+u+2603<ctrl>")
> keyboard.send_keys("<ctrl>+<shift>+u+2603<enter>")
> keyboard.send_keys("<ctrl>+<shift>+u+2603<shift>")
> #Print a snowman with a period after it by sending a plus sign as an
> additional keypress to avoid displaying a tooltip that requires user
> intervention:
> keyboard.send_keys("<ctrl>+<shift>+u+2603+.")
> |
>

> --
> You received this message because you are subscribed to the Google
> Groups "autokey-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to autokey-user...@googlegroups.com
> <mailto:autokey-user...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/autokey-users/0e8c0be5-67e5-476a-a0dd-10b7fa5d59b1o%40googlegroups.com
> <https://groups.google.com/d/msgid/autokey-users/0e8c0be5-67e5-476a-a0dd-10b7fa5d59b1o%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Little Girl]

Hey there,

Joe wrote:

>God bless sed! This is what it was invented for. I see no obvious
>reason to use AutoKey for this at all. One relatively simple regex
>in one line of code any you're done.

Only if you don't want the replacements to happen on-the-fly.
Otherwise, AutoKey would be needed. A combination of both would make
for a truly elegant solution. As an alternative, the whole thing could
be coded in Python.

>It gets a little trickier if you want to support multiple quoting
>styles because you have to deal with the shell trying to expand the
>sed command tokens.

Yep, but I think someone already did all the work on that, right?

--
Little Girl

There is no spoon.

[Little Girl]

Hey there,

Joe wrote:

>This is very nice. Your detailed examples are quite useful.

Thanks. I'm glad you like them.

I actually missed putting in a couple of uXXXX and u+XXXX examples,
but you get the idea from the couple that were in there. It doesn't
seem to make any difference which of those two styles you use, but
since both worked and there could be a time when you want to break
them up like that, I thought I'd add them.

[Joe]

Not sure what you're referring to.

Generally, sed uses a lot of tokens that bash and other shells
recognize/expand and generally cause mischief with, so the usual
approach is to put the whole sed "program" in single quotes. The problem
with this is that there's no easy way to have your cake and eat it by
introducing variables into the sed program - like what quote character
to use. You either have to dynamically build the program in a separate
file or have multiple sed programs and choose the one you need at the
moment with control flow statements. Given that this is Linux, I can
think of several other ways to address this, but they are progressively
more convoluted.

awk nicely handles the same problem by letting you define variables on
its command line which can then be referenced within the body of the awk
program which can still be surrounded by single quotes.

[Little Girl]

Hey there,

Joe wrote:
>Little Girl wrote:

>> Joe wrote:

>>> It gets a little trickier if you want to support multiple quoting
>>> styles because you have to deal with the shell trying to expand
>>> the sed command tokens.
>> Yep, but I think someone already did all the work on that, right?
>Not sure what you're referring to.

Johnny Rosenberg's post in this thread on October 4 includes and uses
a QuotationMarks dictionary that supports several quoting styles.
That dictionary would work nicely in an AutoKey script.

>Generally, sed uses a lot of tokens that bash and other shells
>recognize/expand and generally cause mischief with, so the usual
>approach is to put the whole sed "program" in single quotes. The
>problem with this is that there's no easy way to have your cake and
>eat it by introducing variables into the sed program - like what
>quote character to use. You either have to dynamically build the
>program in a separate file or have multiple sed programs and choose
>the one you need at the moment with control flow statements. Given
>that this is Linux, I can think of several other ways to address
>this, but they are progressively more convoluted.

I've never done anything so fancy with it. My only use of sed has
been as part of a single line of code in which it and a few other
commands all got together to make magic happen on a piece of text. As
a result, my efforts would probably be clumsy and awkward, but I
suspect it would be fun to try to do.

>awk nicely handles the same problem by letting you define variables
>on its command line which can then be referenced within the body of
>the awk program which can still be surrounded by single quotes.

I suppose single quotes can also be escaped, when needed, to get
around any issues with them.

Speaking of single quotes, I hadn't even thought about those when
pondering this whole replacement thing. I don't like curly quotes, so
I turn them off by default in all word-processing programs. As a
result, I'd completely forgotten that apostrophes or any other use of
single quotes are also represented with curly quotes. Those are easy
to deal with, though, since they don't come in pairs, so any blanket
search-and-replace will work on them without any counting or
awareness of others being necessary.

The most complicated part of any script that handles this will be
that it needs to get the lay of the land when it comes to identifying
the presence (or lack thereof) of those double-quote pairs and which
one of the pair it's currently dealing with.

[Joe]

I think what's happening is you're thinking in AutoKey/Python and I'm
thinking in bash.

I'm not trying to do anything "net" fancy. I'm saying that in bash
(without AutoKey) you can't easily modify a sed program because it is
either completely static enclosed in single quotes or completely
vulnerable to bash expansions and protecting it token by token is ugly
at best.

>> awk nicely handles the same problem by letting you define variables
>> on its command line which can then be referenced within the body of
>> the awk program which can still be surrounded by single quotes.
> I suppose single quotes can also be escaped, when needed, to get
> around any issues with them.
>
> Speaking of single quotes, I hadn't even thought about those when
> pondering this whole replacement thing. I don't like curly quotes, so
> I turn them off by default in all word-processing programs. As a
> result, I'd completely forgotten that apostrophes or any other use of
> single quotes are also represented with curly quotes. Those are easy
> to deal with, though, since they don't come in pairs, so any blanket
> search-and-replace will work on them without any counting or
> awareness of others being necessary.
>
> The most complicated part of any script that handles this will be
> that it needs to get the lay of the land when it comes to identifying
> the presence (or lack thereof) of those double-quote pairs and which
> one of the pair it's currently dealing with.

That's why I like sed or awk. You can give them patterns/regexes that
match what you need to find and replace and you don't need to do the
searching/parsing yourself.
>

[Little Girl]

Hey there,

Joe wrote:

>I think what's happening is you're thinking in AutoKey/Python and I'm
>thinking in bash.

That sounds about right.

>Little Girl wrote:
>> Joe wrote:

>I'm not trying to do anything "net" fancy. I'm saying that in bash
>(without AutoKey) you can't easily modify a sed program because it is
>either completely static enclosed in single quotes or completely
>vulnerable to bash expansions and protecting it token by token is
>ugly at best.

Can't you pipe them one after another within a single line of code?
Some of us have been known to occasionally string together an obscene
number of them to get a particular job done from time to time.

>> The most complicated part of any script that handles this will be
>> that it needs to get the lay of the land when it comes to
>> identifying the presence (or lack thereof) of those double-quote
>> pairs and which one of the pair it's currently dealing with.

>That's why I like sed or awk. You can give them patterns/regexes that
>match what you need to find and replace and you don't need to do the
>searching/parsing yourself.

Okay. It sounds like you'd be useful in writing that when the time
comes. I still tend to flail about with wild abandon in pretty much
complete chaos when it comes to regular expressions and only
sometimes manage to accidentally get them working.

[Joe]

On 10/9/20 11:41 PM, Little Girl wrote:
> Hey there,
>
> Joe wrote:
>
>> I think what's happening is you're thinking in AutoKey/Python and I'm
>> thinking in bash.
> That sounds about right.
>
>> Little Girl wrote:
>>> Joe wrote:
>> I'm not trying to do anything "net" fancy. I'm saying that in bash
>> (without AutoKey) you can't easily modify a sed program because it is
>> either completely static enclosed in single quotes or completely
>> vulnerable to bash expansions and protecting it token by token is
>> ugly at best.
> Can't you pipe them one after another within a single line of code?
> Some of us have been known to occasionally string together an obscene
> number of them to get a particular job done from time to time.

Sure, but that doesn't affect quoting/escaping.

Also, some people don't realize that one sed program can contain as many
sed commands as necessary, not just one.

sed '
s/abc/def/
...
s/ghi/jkl/
' input-file > output-file

Each input line gets processed sequentially through each of the
commands. That can simplify writing the code and makes it run lighter
because it only has one sed process, not a bunch of them piped together.

>>> The most complicated part of any script that handles this will be
>>> that it needs to get the lay of the land when it comes to
>>> identifying the presence (or lack thereof) of those double-quote
>>> pairs and which one of the pair it's currently dealing with.
>> That's why I like sed or awk. You can give them patterns/regexes that
>> match what you need to find and replace and you don't need to do the
>> searching/parsing yourself.
> Okay. It sounds like you'd be useful in writing that when the time
> comes. I still tend to flail about with wild abandon in pretty much
> complete chaos when it comes to regular expressions and only
> sometimes manage to accidentally get them working.

I read a whole O'Reiley book on regexes and I still don't understand
them very well, but I use the simple ones frequently enough that I
usually get them right fairly quickly.

regex programming rules:

Regexes are mostly write-only code. If it doesn't work after a couple of
tries, start over.

If you're having any trouble getting sed to do something, give up and
rewrite it in awk. awk is way easier to program and orders of magnitude
easier to debug. For most situations, it's almost as fast as sed and
your time (and sanity!) are worth more. I'm a big fan of awk.

There was a great Xkcd or similar cartoon that I can no longer find. One
person is typing at a terminal and another, looking over her shoulder
says,"You've become a really advanced programmer. I can't tell if that's
a regex or line noise." (You have to remember the old days of acoustic
modems to know what line noise was - essentially random characters
caused by a bad analog phone line.)

The operative, famous quote is:

Some people, when confronted with a problem, think
“I know, I'll use regular expressions.”
Now they have two problems.

Joe

[Little Girl]

Hey there,

Joe wrote:
>Little Girl wrote:
>> Joe wrote:

>>> I'm not trying to do anything "net" fancy. I'm saying that in bash
>>> (without AutoKey) you can't easily modify a sed program because
>>> it is either completely static enclosed in single quotes or
>>> completely vulnerable to bash expansions and protecting it token
>>> by token is ugly at best.

>> Can't you pipe them one after another within a single line of code?
>> Some of us have been known to occasionally string together an
>> obscene number of them to get a particular job done from time to
>> time.

>Sure, but that doesn't affect quoting/escaping.

Ah, I misunderstood.

>Also, some people don't realize that one sed program can contain as
>many sed commands as necessary, not just one.
>
>sed '
>s/abc/def/
>...
>s/ghi/jkl/
>' input-file > output-file
>
>Each input line gets processed sequentially through each of the
>commands. That can simplify writing the code and makes it run lighter
>because it only has one sed process, not a bunch of them piped
>together.

Nice. I hadn't realized you could do that. It seems you can also turn
that into a one-liner by putting semi-colons at the end of each of
those lines and running them all together.

>I read a whole O'Reiley book on regexes and I still don't understand
>them very well, but I use the simple ones frequently enough that I
>usually get them right fairly quickly.

That gives you a head-start in being able to figure out how this
could be done.

>regex programming rules:
>
>Regexes are mostly write-only code. If it doesn't work after a
>couple of tries, start over.

Good to know.

>If you're having any trouble getting sed to do something, give up and
>rewrite it in awk. awk is way easier to program and orders of
>magnitude easier to debug. For most situations, it's almost as fast
>as sed and your time (and sanity!) are worth more. I'm a big fan of
>awk.

Is there a reason why either or both of those would be better than
Python for this or is it just a matter of preference?

>There was a great Xkcd or similar cartoon that I can no longer find.
>One person is typing at a terminal and another, looking over her
>shoulder says,"You've become a really advanced programmer. I can't
>tell if that's a regex or line noise." (You have to remember the old
>days of acoustic modems to know what line noise was - essentially
>random characters caused by a bad analog phone line.)

Heh.

>The operative, famous quote is:
>
>Some people, when confronted with a problem, think
>“I know, I'll use regular expressions.”
>Now they have two problems.

I love this. Consider it stolen and shared.

[Joe]

On 10/11/20 3:00 PM, Little Girl wrote:
> Hey there,
>
> Joe wrote:
>> Little Girl wrote:
>>> Joe wrote:
>
>>>> I'm not trying to do anything "net" fancy. I'm saying that in bash
>>>> (without AutoKey) you can't easily modify a sed program because
>>>> it is either completely static enclosed in single quotes or
>>>> completely vulnerable to bash expansions and protecting it token
>>>> by token is ugly at best.
>>> Can't you pipe them one after another within a single line of code?
>>> Some of us have been known to occasionally string together an
>>> obscene number of them to get a particular job done from time to
>>> time.
>> Sure, but that doesn't affect quoting/escaping.
> Ah, I misunderstood.

I found out how to do it!

sed -re 's/'"$Left_Quote"'/"/g'

Basically, you split the sed command into the piece before your shell
variable and the piece after it.

Those two pieces get surrounded by single quotes to keep the shell at
bay. Then the variable gets sandwiched between them and it gets enclosed
in double quotes in case it has embedded blanks in it.

The above code was *not* tested. The replacement double quote might need
a backslash in front of it, etc. It's just so you can see what it looks
like in general.

You could do the same thing with multiple variables in one sed command,
but the above example is ugly enough!

>
>> Also, some people don't realize that one sed program can contain as
>> many sed commands as necessary, not just one.
>>
>> sed '
>> s/abc/def/
>> ...
>> s/ghi/jkl/
>> ' input-file > output-file
>>
>> Each input line gets processed sequentially through each of the
>> commands. That can simplify writing the code and makes it run lighter
>> because it only has one sed process, not a bunch of them piped
>> together.
> Nice. I hadn't realized you could do that. It seems you can also turn
> that into a one-liner by putting semi-colons at the end of each of
> those lines and running them all together.

That will work, but sed is far too unreadable to do anything to make it
even harder to read!

>
>> I read a whole O'Reiley book on regexes and I still don't understand
>> them very well, but I use the simple ones frequently enough that I
>> usually get them right fairly quickly.
> That gives you a head-start in being able to figure out how this
> could be done.
>
>> regex programming rules:
>>
>> Regexes are mostly write-only code. If it doesn't work after a
>> couple of tries, start over.
> Good to know.
>
>> If you're having any trouble getting sed to do something, give up and
>> rewrite it in awk. awk is way easier to program and orders of
>> magnitude easier to debug. For most situations, it's almost as fast
>> as sed and your time (and sanity!) are worth more. I'm a big fan of
>> awk.
> Is there a reason why either or both of those would be better than
> Python for this or is it just a matter of preference?

Some of each. sed is blazingly fast if you have very large files. It
will run circles around Python and beat out awk by a little bit.

The beauty of both sed and awk is that they have an implied input loop
that you don't have to code. Whatever they do, they do to each line of
input in turn.
It's Linux, so of course you can mess with that in various ways, but the
default just works.

With both, the regex capabilities are built-in so all you do is specify
the regex and go. No imports ...

awk has a number of extremely handy built-in variables/parameters. FS is
the field separator and defaults to white space. If you want the third
word in the line, it's just $3 with no other work. It gets used for that
alone in a lot of bash scripts. If you set FS=',', now you're parsing
CSV files for free (if there aren't any commas embedded in strings.)
Need the last field on every line, it's $NF. Need the current line
number, it's $NR and the list goes on. It can also keep track of things
on a per file basis if you give it more than one input file. That's a
whole lot of code you don't have to write.

The big advantage of awk is that it has code blocks and print statements
so you can break complex operations into smaller pieces and print out
intermediate results to see if the pieces are working as expected. sed
either works or it doesn't and won't tell you why.

As your application grows in complexity, the advantages of awk over
Python decrease, but you'd be amazed by what a few lines of awk can
accomplish.

Examples attached.

jdf - pretty print/simplify the output of df (disk free space). I also
have a wrapper script for this (kdf) that outputs it in a GUI dialog box.

flow - turns a file with lots of newlines in it in into multiple
paragraphs preserving empty lines. It has a bunch of extra print
statements that don't do anything by default that document what the
program is doing if  you direct their output to somewhere besides
/dev/null. That makes it look longer.

Look Ma, no loop! (It's implied.)

You could get a Python version of this one almost this short.

Joe

>
>> There was a great Xkcd or similar cartoon that I can no longer find.
>> One person is typing at a terminal and another, looking over her
>> shoulder says,"You've become a really advanced programmer. I can't
>> tell if that's a regex or line noise." (You have to remember the old
>> days of acoustic modems to know what line noise was - essentially
>> random characters caused by a bad analog phone line.)
> Heh.
>
>> The operative, famous quote is:
>>
>> Some people, when confronted with a problem, think
>> “I know, I'll use regular expressions.”
>> Now they have two problems.
> I love this. Consider it stolen and shared.
>

It's not mine. Type regex humor into duckduckgo. You'll be pleasantly
surprised.

[Little Girl]

Hey there,

Joe wrote:
>Little Girl wrote:
>> Joe wrote:

>>>>> I'm saying that in bash (without AutoKey) you can't easily
>>>>> modify a sed program because it is either completely static
>>>>> enclosed in single quotes or completely vulnerable to bash
>>>>> expansions and protecting it token by token is ugly at best.

[SNIP]

>I found out how to do it!
>
>sed -re 's/'"$Left_Quote"'/"/g'
>
>Basically, you split the sed command into the piece before your shell
>variable and the piece after it.

Ah, so this would surround a single selection?

>Those two pieces get surrounded by single quotes to keep the shell at
>bay. Then the variable gets sandwiched between them and it gets
>enclosed in double quotes in case it has embedded blanks in it.

Yep, it seems that that's what it would do. I think the OP in this
thread wants an on-the-fly AutoKey script that will automatically add
in the left and right quotes as you type them, which will be way more
convoluted to code since the code has to figure out which of the two
quotes it needs to put in at any given moment.

>The above code was *not* tested. The replacement double quote might
>need a backslash in front of it, etc. It's just so you can see what
>it looks like in general.

Okay, no worries. I'll wait until you have it inside of an AutoKey script.

>You could do the same thing with multiple variables in one sed
>command, but the above example is ugly enough!

Heh.

>>> Also, some people don't realize that one sed program can contain
>>> as many sed commands as necessary, not just one.

[SNIP]

>> Nice. I hadn't realized you could do that. It seems you can also
>> turn that into a one-liner by putting semi-colons at the end of
>> each of those lines and running them all together.

>That will work, but sed is far too unreadable to do anything to make
>it even harder to read!

Believe it or not, I have an easier time with one-liners that contain
semi-colons than I do with multi-line code.

>>> If you're having any trouble getting sed to do something, give up
>>> and rewrite it in awk. awk is way easier to program and orders of
>>> magnitude easier to debug. For most situations, it's almost as
>>> fast as sed and your time (and sanity!) are worth more. I'm a big
>>> fan of awk.

>> Is there a reason why either or both of those would be better than
>> Python for this or is it just a matter of preference?

>Some of each. sed is blazingly fast if you have very large files. It
>will run circles around Python and beat out awk by a little bit.

That's always important to know, especially if one is dealing with
large amounts of data.

>The beauty of both sed and awk is that they have an implied input
>loop that you don't have to code. Whatever they do, they do to each
>line of input in turn.
>It's Linux, so of course you can mess with that in various ways, but
>the default just works.

Good to know.

>With both, the regex capabilities are built-in so all you do is
>specify the regex and go. No imports ...

Oh, now that's interesting. I didn't realize such a thing was
possible. I may have to revisit both of these just to do a bit of
mental stretching.

>awk has a number of extremely handy built-in variables/parameters.
>FS is the field separator and defaults to white space. If you want
>the third word in the line, it's just $3 with no other work. It gets
>used for that alone in a lot of bash scripts. If you set FS=',', now
>you're parsing CSV files for free (if there aren't any commas
>embedded in strings.) Need the last field on every line, it's $NF.
>Need the current line number, it's $NR and the list goes on. It can
>also keep track of things on a per file basis if you give it more
>than one input file. That's a whole lot of code you don't have to
>write.

Nice. I would, of course, have a handy cheat sheet that contains them
all for quick reference.

>The big advantage of awk is that it has code blocks and print
>statements so you can break complex operations into smaller pieces
>and print out intermediate results to see if the pieces are working
>as expected. sed either works or it doesn't and won't tell you why.

Oh, good heavens. Sed sounds like a recipe for hair-pulling.

>As your application grows in complexity, the advantages of awk over
>Python decrease, but you'd be amazed by what a few lines of awk can
>accomplish.

Definitely, especially since I have very little experience with it
and my only use of it has been after fetching snippets of code from
StackExchange or a similar place when needed. I'm a complete n00b
when it comes to awk and sed.

>Examples attached.

Thanks.

>jdf - pretty print/simplify the output of df (disk free space). I
>also have a wrapper script for this (kdf) that outputs it in a GUI
>dialog box.

>flow - turns a file with lots of newlines in it in into multiple
>paragraphs preserving empty lines. It has a bunch of extra print
>statements that don't do anything by default that document what the
>program is doing if  you direct their output to somewhere besides
>/dev/null. That makes it look longer.

Interesting. It would definitely take some learning. Some of it looks
like Greek to me.

>Look Ma, no loop! (It's implied.)

Very nice.

>You could get a Python version of this one almost this short.

Some day.

[Joe]

On 10/13/20 12:11 PM, Little Girl wrote:
> Hey there,
>
> Joe wrote:
>> Little Girl wrote:
>>> Joe wrote:
>
>>>>>> I'm saying that in bash (without AutoKey) you can't easily
>>>>>> modify a sed program because it is either completely static
>>>>>> enclosed in single quotes or completely vulnerable to bash
>>>>>> expansions and protecting it token by token is ugly at best.
> [SNIP]
>
>> I found out how to do it!
>>
>> sed -re 's/'"$Left_Quote"'/"/g'
>>
>> Basically, you split the sed command into the piece before your shell
>> variable and the piece after it.
> Ah, so this would surround a single selection?

Not following what you mean.

The above sed program will read a file (stdin/pipe, by default) and
replace all occurrences of whatever is stored in Left_Quote (assigned in
the rest of the bash script it would be contained in) with a single
double quote character. You would add a line to it to similarly handle
the right quotes and have some way of setting both of those variables in
the preceding lines of bash code.

>
>> Those two pieces get surrounded by single quotes to keep the shell at
>> bay. Then the variable gets sandwiched between them and it gets
>> enclosed in double quotes in case it has embedded blanks in it.
> Yep, it seems that that's what it would do. I think the OP in this
> thread wants an on-the-fly AutoKey script that will automatically add
> in the left and right quotes as you type them, which will be way more
> convoluted to code since the code has to figure out which of the two
> quotes it needs to put in at any given moment.

That's why I suggested sed/awk. It looked like the original problem was
an xy problem. How often would you have a document where you only wanted
to modify the quoting style for some of the quotes, but not all of them?
Mixed language documents aren't that common - at least in my experience.

>
>> The above code was *not* tested. The replacement double quote might
>> need a backslash in front of it, etc. It's just so you can see what
>> it looks like in general.
> Okay, no worries. I'll wait until you have it inside of an AutoKey script.

I'm not planning on implementing it unless someone needs it.

>
>> You could do the same thing with multiple variables in one sed
>> command, but the above example is ugly enough!
> Heh.
>
>>>> Also, some people don't realize that one sed program can contain
>>>> as many sed commands as necessary, not just one.
> [SNIP]
>
>>> Nice. I hadn't realized you could do that. It seems you can also
>>> turn that into a one-liner by putting semi-colons at the end of
>>> each of those lines and running them all together.
>> That will work, but sed is far too unreadable to do anything to make
>> it even harder to read!
> Believe it or not, I have an easier time with one-liners that contain
> semi-colons than I do with multi-line code.

Wow. People really do think differently.

>
>>>> If you're having any trouble getting sed to do something, give up
>>>> and rewrite it in awk. awk is way easier to program and orders of
>>>> magnitude easier to debug. For most situations, it's almost as
>>>> fast as sed and your time (and sanity!) are worth more. I'm a big
>>>> fan of awk.
>>> Is there a reason why either or both of those would be better than
>>> Python for this or is it just a matter of preference?
>> Some of each. sed is blazingly fast if you have very large files. It
>> will run circles around Python and beat out awk by a little bit.
> That's always important to know, especially if one is dealing with
> large amounts of data.
>
>> The beauty of both sed and awk is that they have an implied input
>> loop that you don't have to code. Whatever they do, they do to each
>> line of input in turn.
>> It's Linux, so of course you can mess with that in various ways, but
>> the default just works.
> Good to know.
>
>> With both, the regex capabilities are built-in so all you do is
>> specify the regex and go. No imports ...
> Oh, now that's interesting. I didn't realize such a thing was
> possible. I may have to revisit both of these just to do a bit of
> mental stretching.

Keep in mind that both sed and awk use ERE syntax which is a little
different from that used by Python. There are  a number of regex dialects.

By default, sed uses BREs (which is why I use the -r flag to turn on
EREs.) The two are quite similar, but EREs are more powerful and when
you use BREs you generally have to add a bunch of backslashes to escape
things that EREs just know about - like parentheses.

Both sed and awk are GNU utilities which, among other things, means that
they have info pages in addition to man pages. Their info pages are much
larger than their man pages and include some explanations and examples.
grep has one of these as well.

>> awk has a number of extremely handy built-in variables/parameters.
>> FS is the field separator and defaults to white space. If you want
>> the third word in the line, it's just $3 with no other work. It gets
>> used for that alone in a lot of bash scripts. If you set FS=',', now
>> you're parsing CSV files for free (if there aren't any commas
>> embedded in strings.) Need the last field on every line, it's $NF.
>> Need the current line number, it's $NR and the list goes on. It can
>> also keep track of things on a per file basis if you give it more
>> than one input file. That's a whole lot of code you don't have to
>> write.
> Nice. I would, of course, have a handy cheat sheet that contains them
> all for quick reference.

I just run man awk into a text file and save it. Then I open that file
in another kate tab so I can search for whatever syntax, flag, or
built-in function I need. Same for sed. I just have to remember to
refresh the files when awk or sed get updates. I do the same for yad.

>
>> The big advantage of awk is that it has code blocks and print
>> statements so you can break complex operations into smaller pieces
>> and print out intermediate results to see if the pieces are working
>> as expected. sed either works or it doesn't and won't tell you why.
> Oh, good heavens. Sed sounds like a recipe for hair-pulling.

It's more of an "I'm a better coder/smarter than you are" nerd thing. :)

But, once you have the basics down, regexes save you a ton of time and
effort and reduce the complexity of the rest of your code significantly.

The tricks are to immediately add comments to your code explaining what
they do step by step so when you (or someone else) come back later you
don't have to analyze them from scratch, and to know when you're out of
your depth - when to give up and code it another, simpler, but less
elegant way that you can actually get working in a reasonable amount of
time.

>
>> As your application grows in complexity, the advantages of awk over
>> Python decrease, but you'd be amazed by what a few lines of awk can
>> accomplish.
> Definitely, especially since I have very little experience with it
> and my only use of it has been after fetching snippets of code from
> StackExchange or a similar place when needed. I'm a complete n00b
> when it comes to awk and sed.

That's the downside of the web. You can find examples and short articles
that show you how to do specific things, but it takes reading a book or
taking a course to really understand how complex things work so you can
come up with new solutions yourself.

>> Examples attached.
> Thanks.
>
>> jdf - pretty print/simplify the output of df (disk free space). I
>> also have a wrapper script for this (kdf) that outputs it in a GUI
>> dialog box.
>> flow - turns a file with lots of newlines in it in into multiple
>> paragraphs preserving empty lines. It has a bunch of extra print
>> statements that don't do anything by default that document what the
>> program is doing if  you direct their output to somewhere besides
>> /dev/null. That makes it look longer.
> Interesting. It would definitely take some learning. Some of it looks
> like Greek to me.

I'd be happy to answer any questions, etc., but it would be better off list.

>> Look Ma, no loop! (It's implied.)
> Very nice.
>
>> You could get a Python version of this one almost this short.
> Some day.

I meant, "one could," not you, me, or anybody else specifically.

Joe

>

[Duns]

Thank you everybody. Excuse me for my long silence. I appreciate very much your efforts, but what I'm searching for is a on-the-fly solution, that is within Autokey, that is when I type something (in kate or in a browser, when I use phpmyadmin to add database items). Therefore Sed could be an interesting way, but it is not for my needs.

To sum up, I'm a bit confused: I still don't understand what (script) I should write to put before and after a selected word a non-ascii (utf8) symbol.

If I not wrong this script doesn't exist yet, does it?

Thank you!

[Joe]

Sorry. That kind of got lost in the larger discussion.

Take another look at Little Girl's post from 10/04/2020 11:28  EDT. I
think that will do what you want - for one language/locale.

If you need more than that, then Johnny Rosenberg's solution for
10/04/20 1:52PM EDT handles that. As written, it selects the type of
quotes to use based  on the locale setting in your operating system.
That's quite easy to change using several different approaches depending
on how you want to decide what quoting style to use and how frequently
you need to change that choice.

Joe

> --
> You received this message because you are subscribed to the Google
> Groups "autokey-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to autokey-user...@googlegroups.com
> <mailto:autokey-user...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/autokey-users/6b77f54f-4480-4dd4-bbc9-c53a78986a30n%40googlegroups.com
> <https://groups.google.com/d/msgid/autokey-users/6b77f54f-4480-4dd4-bbc9-c53a78986a30n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Little Girl]

Hey there,

Joe wrote:
>Little Girl wrote:
>> Joe wrote:

>>> Those two pieces get surrounded by single quotes to keep the
>>> shell at bay. Then the variable gets sandwiched between them and
>>> it gets enclosed in double quotes in case it has embedded blanks
>>> in it.

>> Yep, it seems that that's what it would do. I think the OP in this
>> thread wants an on-the-fly AutoKey script that will automatically
>> add in the left and right quotes as you type them, which will be
>> way more convoluted to code since the code has to figure out which
>> of the two quotes it needs to put in at any given moment.

>That's why I suggested sed/awk. It looked like the original problem
>was an xy problem. How often would you have a document where you
>only wanted to modify the quoting style for some of the quotes, but
>not all of them? Mixed language documents aren't that common - at
>least in my experience.

I'm not sure. The original OP had wanted an on-the-fly solution and
then decided that a selection solution would be good enough. Each
would need a different approach, but sed would be useful for either.

>> I'll wait until you have it inside of an AutoKey script.

>I'm not planning on implementing it unless someone needs it.

Ah, okay. Well, it looks like the OP will be able to use one of the
already-suggested solutions, so there's no need, but making it into
an on-the-fly solution is an intriguing idea that I may put on my
list of things to play around with.

>>> With both, the regex capabilities are built-in so all you do is
>>> specify the regex and go. No imports ...

>> Oh, now that's interesting. I didn't realize such a thing was
>> possible. I may have to revisit both of these just to do a bit of
>> mental stretching.

>Keep in mind that both sed and awk use ERE syntax which is a little
>different from that used by Python. There are  a number of regex
>dialects.

Oh, good heavens. It might be time for me to run away and go hide
again. It sure would be nice if the developers of all these languages
would agree on standards.

>Both sed and awk are GNU utilities which, among other things, means
>that they have info pages in addition to man pages. Their info pages
>are much larger than their man pages and include some explanations
>and examples. grep has one of these as well.

Oh, my. I've used GNU/Linux for years and didn't know about these.
Thanks. I'm now going to be checking for those from now on in all
future GNU programs.

>> Nice. I would, of course, have a handy cheat sheet that contains
>> them all for quick reference.

>I just run man awk into a text file and save it. Then I open that
>file in another kate tab so I can search for whatever syntax, flag,
>or built-in function I need. Same for sed. I just have to remember to
>refresh the files when awk or sed get updates. I do the same for yad.

I do the same, but destroy the file immediately afterwards rather
than trusting myself to remember to update it. Not only that, but I
often don't need that particular man page again, so there's usually no
need to keep it around.

>>> The big advantage of awk is that it has code blocks and print
>>> statements so you can break complex operations into smaller pieces
>>> and print out intermediate results to see if the pieces are
>>> working as expected. sed either works or it doesn't and won't
>>> tell you why.

>> Oh, good heavens. Sed sounds like a recipe for hair-pulling.

>It's more of an "I'm a better coder/smarter than you are" nerd
>thing. :)

>But, once you have the basics down, regexes save you a ton of time
>and effort and reduce the complexity of the rest of your code
>significantly.

>The tricks are to immediately add comments to your code explaining
>what they do step by step so when you (or someone else) come back
>later you don't have to analyze them from scratch, and to know when
>you're out of your depth - when to give up and code it another,
>simpler, but less elegant way that you can actually get working in a
>reasonable amount of time.

I think you can tell that I do that sort of thing already and I wish
everyone did. Not only does it help us to remember what we did in
our own code when we revisit it far later, but it can also let you
know how other people's code works and even if you understand someone
else's code, their notes can be a useful way to figure out why they
coded something the way they did.

>That's the downside of the web. You can find examples and short
>articles that show you how to do specific things, but it takes
>reading a book or taking a course to really understand how complex
>things work so you can come up with new solutions yourself.

Yep.