Re: stuff in ~/bin won't run
I know this is old stuff, but... On Tue,13.Jan.09, 11:10:49, JoeHill wrote: I'm used to ~/bin being automatically picked up in my path, so therefore I am absolutely clueless as to how to add it. Also, considering the potential consequences to my system, I would rather not do it the wrong way ;) This was what came up on a search, is this correct? export PATH =$PATH:/new/path/to/add On a new sid install I have this: ,[ ~/.profile ] | # ~/.profile: executed by the command interpreter for login shells. | # This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login | # exists. | # see /usr/share/doc/bash/examples/startup-files for examples. | # the files are located in the bash-doc package. | | # the default umask is set in /etc/profile; for setting the umask | # for ssh logins, install and configure the libpam-umask package. | #umask 022 | | # if running bash | if [ -n $BASH_VERSION ]; then | # include .bashrc if it exists | if [ -f $HOME/.bashrc ]; then | . $HOME/.bashrc | fi | fi | | # set PATH so it includes user's private bin if it exists | if [ -d $HOME/bin ] ; then | PATH=$HOME/bin:$PATH | fi ` and there is no .bash_profile. This works with gdm. On my former system I had mostly the same stuff in .bash_profile, but had to setup my terminal emulator to start a login shell (because /bin/sh - dash). Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: stuff in ~/bin won't run
Dotan Cohen dotanco...@gmail.com wrote: Thanks, Mike. Actually, rather than be busy for hours, I do wish that there were some document that explains what gets run where, clearly. I have yet to find one. Put these lines in your .bashrc and .bash_profile and you'll see what gets run when # bashrc echo Running bashrc: `date` $HOME/.bash.log test -t 1 echo Running bashrc: `date` # bash_profile echo Running bash_profile: `date` $HOME/.bash.log test -t 1 echo Running bash_profile: `date` What I find works for me is to put all the run once stuff into one file, and all the run each time I start a terminal stuff in the other: # bashrc test -z $DONE_ONCE . $HOME/.bash_runonce test -z $DONE_EACH . $HOME/.bash_runeach # bash_profile test -z $DONE_ONCE . $HOME/.bash_runonce test -z $DONE_EACH . $HOME/.bash_runeach # bash_runonce export DONE_ONCE=true ... # bash_runeach DONE_EACH=true # NB no export ... Chris -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: stuff in ~/bin won't run
Mike Castle wrote: On Wed, Jan 14, 2009 at 8:33 AM, JoeHill joeh...@teksavvy.com wrote: The funny thing is, I already have this in my .bash_profile: # set PATH so it includes user's private bin if it exists if [ -d ~/bin ] ; then PATH=~/bin:${PATH} fi I don't think .bash_profile gets sourced when you log in via an XDM/GDM type session. (After all, when would it, since you don't really have a login shell.) Personally, I have it in my .bashrc, though that has it's own set of drawbacks. If you do some searches about debian and sourcing login shells and gdm, you'll find more than enough reading material to keep you busy for hours. Or, I could just set it up the way I always used to have it, no GDM (goddamned display manager?), just a text-mode login. I used to have an option for 'automatically start X when computer boots', which I would disable. What is the 'Debian Way' for this? ;) -- J -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: stuff in ~/bin won't run
Mike Castle wrote: On Wed, Jan 14, 2009 at 8:33 AM, JoeHill joeh...@teksavvy.com wrote: The funny thing is, I already have this in my .bash_profile: # set PATH so it includes user's private bin if it exists if [ -d ~/bin ] ; then PATH=~/bin:${PATH} fi I don't think .bash_profile gets sourced when you log in via an XDM/GDM type session. (After all, when would it, since you don't really have a login shell.) Personally, I have it in my .bashrc, though that has it's own set of drawbacks. If you do some searches about debian and sourcing login shells and gdm, you'll find more than enough reading material to keep you busy for hours. Or, I could just set it up the way I always used to have it, no GDM (goddamned display manager?), just a text-mode login. I used to have an option for 'automatically start X when computer boots', which I would disable. What is the 'Debian Way' for this? ;) -- J -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: stuff in ~/bin won't run
On Sun, Jan 18, 2009 at 08:07:11PM -0500, JoeHill wrote: I used to have an option for 'automatically start X when computer boots', which I would disable. What is the 'Debian Way' for this? ;) Unless you want it for other users, simplest is probably to remove gdm and install xinit (if not already there) for startx. -- Ken Irving -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: stuff in ~/bin won't run
JoeHill wrote: Could you not just give your versions of the apps you want to run different names? Would that not be safer? What I've done in the past is to add _mine to end of the names, ie. 'todisc_mine'. This approach will be a PITA if you use tab completion. Inputting _ is more painful (especially after pressing tab 2 times for possible list of completions). I'd go for a different name. raju -- Kamaraju S Kusumanchi http://malayamaarutham.blogspot.com/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: stuff in ~/bin won't run
On Wed, Jan 14, 2009 at 04:16:57PM -0800, Mike Castle wrote: On Wed, Jan 14, 2009 at 8:33 AM, JoeHill joeh...@teksavvy.com wrote: The funny thing is, I already have this in my .bash_profile: # set PATH so it includes user's private bin if it exists if [ -d ~/bin ] ; then PATH=~/bin:${PATH} fi I don't think .bash_profile gets sourced when you log in via an XDM/GDM type session. (After all, when would it, since you don't really have a login shell.) Possible fix: echo 'if [ $SHELL = /bin/bash ]; then . $HOME/.bash_profile; fi' /etc/X11/Xsession.d/91bash_profile This looks all too simple so someone must have thought of it previously and decided not to use it. Why? -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best ICQ# 16849754 || friend -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: stuff in ~/bin won't run
2009/1/15 Mike Castle dalgoda+deb...@gmail.com: On Wed, Jan 14, 2009 at 8:33 AM, JoeHill joeh...@teksavvy.com wrote: The funny thing is, I already have this in my .bash_profile: # set PATH so it includes user's private bin if it exists if [ -d ~/bin ] ; then PATH=~/bin:${PATH} fi I don't think .bash_profile gets sourced when you log in via an XDM/GDM type session. (After all, when would it, since you don't really have a login shell.) Personally, I have it in my .bashrc, though that has it's own set of drawbacks. If you do some searches about debian and sourcing login shells and gdm, you'll find more than enough reading material to keep you busy for hours. mrc Thanks, Mike. Actually, rather than be busy for hours, I do wish that there were some document that explains what gets run where, clearly. I have yet to find one. -- Dotan Cohen http://what-is-what.com http://gibberish.co.il א-ב-ג-ד-ה-ו-ז-ח-ט-י-ך-כ-ל-ם-מ-ן-נ-ס-ע-ף-פ-ץ-צ-ק-ר-ש-ת ا-ب-ت-ث-ج-ح-خ-د-ذ-ر-ز-س-ش-ص-ض-ط-ظ-ع-غ-ف-ق-ك-ل-م-ن-ه-و-ي А-Б-В-Г-Д-Е-Ё-Ж-З-И-Й-К-Л-М-Н-О-П-Р-С-Т-У-Ф-Х-Ц-Ч-Ш-Щ-Ъ-Ы-Ь-Э-Ю-Я а-б-в-г-д-е-ё-ж-з-и-й-к-л-м-н-о-п-р-с-т-у-ф-х-ц-ч-ш-щ-ъ-ы-ь-э-ю-я ä-ö-ü-ß-Ä-Ö-Ü
Re: stuff in ~/bin won't run
Tzafrir Cohen tzaf...@cohens.org.il writes: On Wed, Jan 14, 2009 at 04:16:57PM -0800, Mike Castle wrote: I don't think .bash_profile gets sourced when you log in via an XDM/GDM type session. (After all, when would it, since you don't really have a login shell.) Possible fix: echo 'if [ $SHELL = /bin/bash ]; then . $HOME/.bash_profile; fi' /etc/X11/Xsession.d/91bash_profile This looks all too simple so someone must have thought of it previously and decided not to use it. Why? Probably because of this line: #!/bin/sh at the start of /etc/X11/Xsession, which is the master script that will source your 91bash_profile script. So, $SHELL will not be /bin/bash and $HOME/.bash_profile will not be sourced. If you try to source .bash_profile unconditionally from there, any bashisms in it will cause Xsession to fail. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: stuff in ~/bin won't run
Dotan Cohen wrote: 2009/1/13 JoeHill joeh...@teksavvy.com: I'm used to ~/bin being automatically picked up in my path, so therefore I am absolutely clueless as to how to add it. Also, considering the potential consequences to my system, I would rather not do it the wrong way ;) This was what came up on a search, is this correct? export PATH =$PATH:/new/path/to/add Yes, so for you it would be: export PATH =$PATH:/bin The funny thing is, I already have this in my .bash_profile: # set PATH so it includes user's private bin if it exists if [ -d ~/bin ] ; then PATH=~/bin:${PATH} fi Note that I personally prefer .bin to bin as then I do not have to see it in my file manager! -- J -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: stuff in ~/bin won't run
On Wed, Jan 14, 2009 at 8:33 AM, JoeHill joeh...@teksavvy.com wrote: The funny thing is, I already have this in my .bash_profile: # set PATH so it includes user's private bin if it exists if [ -d ~/bin ] ; then PATH=~/bin:${PATH} fi I don't think .bash_profile gets sourced when you log in via an XDM/GDM type session. (After all, when would it, since you don't really have a login shell.) Personally, I have it in my .bashrc, though that has it's own set of drawbacks. If you do some searches about debian and sourcing login shells and gdm, you'll find more than enough reading material to keep you busy for hours. mrc -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: stuff in ~/bin won't run
2009/1/13 JoeHill joeh...@teksavvy.com: I'm used to ~/bin being automatically picked up in my path, so therefore I am absolutely clueless as to how to add it. Also, considering the potential consequences to my system, I would rather not do it the wrong way ;) This was what came up on a search, is this correct? export PATH =$PATH:/new/path/to/add Yes, so for you it would be: export PATH =$PATH:/bin Note that I personally prefer .bin to bin as then I do not have to see it in my file manager! -- Dotan Cohen http://what-is-what.com http://gibberish.co.il א-ב-ג-ד-ה-ו-ז-ח-ט-י-ך-כ-ל-ם-מ-ן-נ-ס-ע-ף-פ-ץ-צ-ק-ר-ש-ת ا-ب-ت-ث-ج-ح-خ-د-ذ-ر-ز-س-ش-ص-ض-ط-ظ-ع-غ-ف-ق-ك-ل-م-ن-ه-و-ي А-Б-В-Г-Д-Е-Ё-Ж-З-И-Й-К-Л-М-Н-О-П-Р-С-Т-У-Ф-Х-Ц-Ч-Ш-Щ-Ъ-Ы-Ь-Э-Ю-Я а-б-в-г-д-е-ё-ж-з-и-й-к-л-м-н-о-п-р-с-т-у-ф-х-ц-ч-ш-щ-ъ-ы-ь-э-ю-я ä-ö-ü-ß-Ä-Ö-Ü
Re: stuff in ~/bin won't run
Sorry, that should have been: PATH=$HOME/bin:$PATH export PATH in your ~/.bash_profile file. Put the new bin BEFORE the old path. -- Dotan Cohen http://what-is-what.com http://gibberish.co.il א-ב-ג-ד-ה-ו-ז-ח-ט-י-ך-כ-ל-ם-מ-ן-נ-ס-ע-ף-פ-ץ-צ-ק-ר-ש-ת ا-ب-ت-ث-ج-ح-خ-د-ذ-ر-ز-س-ش-ص-ض-ط-ظ-ع-غ-ف-ق-ك-ل-م-ن-ه-و-ي А-Б-В-Г-Д-Е-Ё-Ж-З-И-Й-К-Л-М-Н-О-П-Р-С-Т-У-Ф-Х-Ц-Ч-Ш-Щ-Ъ-Ы-Ь-Э-Ю-Я а-б-в-г-д-е-ё-ж-з-и-й-к-л-м-н-о-п-р-с-т-у-ф-х-ц-ч-ш-щ-ъ-ы-ь-э-ю-я ä-ö-ü-ß-Ä-Ö-Ü
Re: stuff in ~/bin won't run
On Tue, Jan 13, 2009 at 8:15 AM, Dotan Cohen dotanco...@gmail.com wrote: Put the new bin BEFORE the old path. Huh? Why? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: stuff in ~/bin won't run
Mike Castle wrote: On Tue, Jan 13, 2009 at 8:15 AM, Dotan Cohen dotanco...@gmail.com wrote: Put the new bin BEFORE the old path. Huh? Why? According to Learning the BASH Shell by Cameron Newham and Bill Rosenblatt it is dangerous to have personal bin directory listed before the public bin directories. I have no idea what the policy is for quoting excerpts from a book so I've chosen to leave it out. If it's ok, I'll be happy to give up the couple of lines. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: stuff in ~/bin won't run
2009/1/13 Daryl Styrk darylst...@gmail.com: Mike Castle wrote: On Tue, Jan 13, 2009 at 8:15 AM, Dotan Cohen dotanco...@gmail.com wrote: Put the new bin BEFORE the old path. Huh? Why? According to Learning the BASH Shell by Cameron Newham and Bill Rosenblatt it is dangerous to have personal bin directory listed before the public bin directories. I have no idea what the policy is for quoting excerpts from a book so I've chosen to leave it out. If it's ok, I'll be happy to give up the couple of lines. The first path with a matching name will be used. So if you have the systemwide /usr/bin/firefox and your own personal ~/bin/firefox you _must_ have your personal bin listed first in the path to get run. Why is that dangerous? Because if your account is compromised then critical system programs (ls, cd, and the like) can be easily replaced with compromised versions. Putting your own bin at the end of the path is meant to thwart this. I have no idea what the policy is for quoting excerpts from a book so I've chosen to leave it out. If it's ok, I'll be happy to give up the couple of lines. Fair use: pretty much it you can type it out in a few lines it's fair game. -- Dotan Cohen http://what-is-what.com http://gibberish.co.il א-ב-ג-ד-ה-ו-ז-ח-ט-י-ך-כ-ל-ם-מ-ן-נ-ס-ע-ף-פ-ץ-צ-ק-ר-ש-ת ا-ب-ت-ث-ج-ح-خ-د-ذ-ر-ز-س-ش-ص-ض-ط-ظ-ع-غ-ف-ق-ك-ل-م-ن-ه-و-ي А-Б-В-Г-Д-Е-Ё-Ж-З-И-Й-К-Л-М-Н-О-П-Р-С-Т-У-Ф-Х-Ц-Ч-Ш-Щ-Ъ-Ы-Ь-Э-Ю-Я а-б-в-г-д-е-ё-ж-з-и-й-к-л-м-н-о-п-р-с-т-у-ф-х-ц-ч-ш-щ-ъ-ы-ь-э-ю-я ä-ö-ü-ß-Ä-Ö-Ü
Re: stuff in ~/bin won't run
On Tue Jan 13, 2009 at 21:08:02 +0200, Dotan Cohen wrote: Why is that dangerous? Because if your account is compromised then critical system programs (ls, cd, and the like) can be easily replaced with compromised versions. Putting your own bin at the end of the path is meant to thwart this. If your account is compromised then why do you imagine your settings will be untouched? People typically put their ~/bin directory first, precisely so that they can override system-wide commands. As for why it didn't work - the OP seemed to have said: PATH = ... (ie. Spaces around the equals sign. This will not work.) Steve -- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: stuff in ~/bin won't run
2009/1/13 Steve Kemp s...@debian.org: On Tue Jan 13, 2009 at 21:08:02 +0200, Dotan Cohen wrote: Why is that dangerous? Because if your account is compromised then critical system programs (ls, cd, and the like) can be easily replaced with compromised versions. Putting your own bin at the end of the path is meant to thwart this. If your account is compromised then why do you imagine your settings will be untouched? Exactly, this is the fallacy. People typically put their ~/bin directory first, precisely so that they can override system-wide commands. Exactly. As for why it didn't work - the OP seemed to have said: PATH = ... (ie. Spaces around the equals sign. This will not work.) I gave him an example of a valid .bash_profile file. -- Dotan Cohen http://what-is-what.com http://gibberish.co.il א-ב-ג-ד-ה-ו-ז-ח-ט-י-ך-כ-ל-ם-מ-ן-נ-ס-ע-ף-פ-ץ-צ-ק-ר-ש-ת ا-ب-ت-ث-ج-ح-خ-د-ذ-ر-ز-س-ش-ص-ض-ط-ظ-ع-غ-ف-ق-ك-ل-م-ن-ه-و-ي А-Б-В-Г-Д-Е-Ё-Ж-З-И-Й-К-Л-М-Н-О-П-Р-С-Т-У-Ф-Х-Ц-Ч-Ш-Щ-Ъ-Ы-Ь-Э-Ю-Я а-б-в-г-д-е-ё-ж-з-и-й-к-л-м-н-о-п-р-с-т-у-ф-х-ц-ч-ш-щ-ъ-ы-ь-э-ю-я ä-ö-ü-ß-Ä-Ö-Ü
Re: stuff in ~/bin won't run
Dotan Cohen wrote: 2009/1/13 Daryl Styrk darylst...@gmail.com: Mike Castle wrote: On Tue, Jan 13, 2009 at 8:15 AM, Dotan Cohen dotanco...@gmail.com wrote: Put the new bin BEFORE the old path. Huh? Why? According to Learning the BASH Shell by Cameron Newham and Bill Rosenblatt it is dangerous to have personal bin directory listed before the public bin directories. I have no idea what the policy is for quoting excerpts from a book so I've chosen to leave it out. If it's ok, I'll be happy to give up the couple of lines. The first path with a matching name will be used. So if you have the systemwide /usr/bin/firefox and your own personal ~/bin/firefox you _must_ have your personal bin listed first in the path to get run. Why is that dangerous? Because if your account is compromised then critical system programs (ls, cd, and the like) can be easily replaced with compromised versions. Putting your own bin at the end of the path is meant to thwart this. I have no idea what the policy is for quoting excerpts from a book so I've chosen to leave it out. If it's ok, I'll be happy to give up the couple of lines. Fair use: pretty much it you can type it out in a few lines it's fair game. This is unsafe because you are trusting that your own version of the more command works properly. But it is also risky for a more important reason: system security. If your PATH is set up in this way, you leave open a hole that is well known to computer crackers and mischief makers: they can install Trojan horses and do other things to steal files or do damage. There is a senerio that goes on to detail how a user with a suid script in their personal bin directory before a public bin. Creating a Trojan that looks for a common utility such as grep.. The example script.. cp /bin/bash filenamechown root filenamechmod 4755 filename/bin/grep $@rm ~/bin/grep Sits back and waits for the user to run the suid shell script—which calls the Trojan horse, which in turn creates the suid shell and then self-destructs. If you have the book I'm looking at chapter 10. 10.3.2 to be exact. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: stuff in ~/bin won't run
Daryl Styrk writes: I have no idea what the policy is for quoting excerpts from a book so 've chosen to leave it out. In the US the policy is the bit of copyright law called Fair Use. It says you can quote excerpts without permission without infringing copyright. -- John Hasler -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: stuff in ~/bin won't run
Dotan Cohen wrote: 2009/1/13 Steve Kemp s...@debian.org: On Tue Jan 13, 2009 at 21:08:02 +0200, Dotan Cohen wrote: Why is that dangerous? Because if your account is compromised then critical system programs (ls, cd, and the like) can be easily replaced with compromised versions. Putting your own bin at the end of the path is meant to thwart this. If your account is compromised then why do you imagine your settings will be untouched? Exactly, this is the fallacy. People typically put their ~/bin directory first, precisely so that they can override system-wide commands. Exactly. Could you not just give your versions of the apps you want to run different names? Would that not be safer? What I've done in the past is to add _mine to end of the names, ie. 'todisc_mine'. As for why it didn't work - the OP seemed to have said: PATH = ... (ie. Spaces around the equals sign. This will not work.) I gave him an example of a valid .bash_profile file. -- J -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: stuff in ~/bin won't run
On 2009-01-13 20:28 +0100, Daryl Styrk wrote: This is unsafe because you are trusting that your own version of the more command works properly. But it is also risky for a more important reason: system security. If your PATH is set up in this way, you leave open a hole that is well known to computer crackers and mischief makers: they can install Trojan horses and do other things to steal files or do damage. The book in general is not so bad, but this statement, in fact the whole paragraph, is just nonsense. There is a senerio that goes on to detail how a user with a suid script in their personal bin directory before a public bin. Creating a Trojan that looks for a common utility such as grep.. For one thing, the suid bit is ignored for scripts on Linux. And your ~/bin directory should never be writable by other people. The example script.. cp /bin/bash filenamechown root filenamechmod 4755 filename/bin/grep $@rm ~/bin/grep Will just not work, unless the user executing the script is root. Sits back and waits for the user to run the suid shell script—which calls the Trojan horse, which in turn creates the suid shell and then self-destructs. If you have the book I'm looking at chapter 10. 10.3.2 to be exact. Do you have the third edition? The second edition which I own does not have sections inside the chapters numbered. Sven -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: stuff in ~/bin won't run
2009/1/13 JoeHill joeh...@teksavvy.com: Could you not just give your versions of the apps you want to run different names? Would that not be safer? What I've done in the past is to add _mine to end of the names, ie. 'todisc_mine'. Depends on what you are doing. Here is a good example of appending locale information to a command, and I _always_ want that: har...@hardy2-laptop:~/.bin$ cat openoffice.org2.3 #!/bin/bash export LC_TIME=en_DK.utf8; /usr/bin/openoffice.org2.3 $@ This is an example of a usage where I want my script to intercept calls to the systemwide program. -- Dotan Cohen http://what-is-what.com http://gibberish.co.il א-ב-ג-ד-ה-ו-ז-ח-ט-י-ך-כ-ל-ם-מ-ן-נ-ס-ע-ף-פ-ץ-צ-ק-ר-ש-ת ا-ب-ت-ث-ج-ح-خ-د-ذ-ر-ز-س-ش-ص-ض-ط-ظ-ع-غ-ف-ق-ك-ل-م-ن-ه-و-ي А-Б-В-Г-Д-Е-Ё-Ж-З-И-Й-К-Л-М-Н-О-П-Р-С-Т-У-Ф-Х-Ц-Ч-Ш-Щ-Ъ-Ы-Ь-Э-Ю-Я а-б-в-г-д-е-ё-ж-з-и-й-к-л-м-н-о-п-р-с-т-у-ф-х-ц-ч-ш-щ-ъ-ы-ь-э-ю-я ä-ö-ü-ß-Ä-Ö-Ü