What steps will reproduce the problem?

menu.lst example...

1. root (bd) € set root to boot drive
2. map (hd0) (hd1) € map hd0 to hd1
3. map (hd1) (hd0) € map hd1 to hd0
4. map --hook € put mapping into effect

What is the expected output? What do you see instead? The € symbol (ALT-GR+4) denotes start of a comment, therefore the line is valid and treated as just root (), map etc.

What version of the product are you using? On what operating system? any

Please provide any additional information below.

The Euro symbol translates as 80 hex when used in Notepad. It would be easy to add code to treat this symbol as a comment character in grub4dos. 80 hex in ASCII is a Ç symbol which is unlikely to be wanted in a grub4dos menu (echo or help text).

code inserted into stage2.c

/* Skip non-printable chars, including the UTF-8 Byte Order Mark: EF BB BF */ if ((unsigned char)c > ' ' && (unsigned char)c <= 0x7F) //((c != ' ') && (c != '\t') && (c != '\n') && (c != '\r')) cmdline[pos++] = c; } } else {

// NEW CODE

if ((unsigned char)c == 0x80)
  {
  info |=2;     // start comment if char = 80 hex
  c = ' ';
  }

works fine.

Also suggest allowing both # or € at start of a line to allow whole line to be a comment.

The above idea of using € will not work as UTF codes contain 80 hex. So instead I suggest we use ## for inline comments. I have already written the code for this and tested it. You could probably write better code as I am not very experienced in C! The main thing is to be careful if the end of line is exceeded.

e.g.

echo # fred # ## this is not printed echo ## this is not printed echo ### all of this line ## is ## printed echo #################

the above line is printed, this one is not

this line is ignored

root () ## set root drive

echo # fred # ## this is not printed

obviously what is printed is

fred

but not the ## or anything after it.

bump - it would be great if you could add this code into the next version?

Sorry, the discussion in Chinese is here: http://bbs.znpc.net/viewthread.php?tid=6137

There are other suggestions. For example, a single # that leads a word, that is, # after a effective white space. Examples for this proposal:

echo ###### this will not be printed echo ##### this will be printed echo this will be printed and## this## will# also# be# printed# but #this will not be printed

Consider case below:

set A=1

Now if want to add a comment to this line using your proposal of #

set A=1 #set the variable A to 1

will make A=1 which is not what we want!

however if we use two ## followed by a as a comment delimiter

set A=1## set the variable A to 1

Then A=1 which is expected

So I propose ## as an inline comment delimiter?

just like "&&" "||"

set a=1 && set b=3 will make a=1 set a=1 && set b=3 will make a=1

true, but with

set a=look at #set a to 'look at ' set b=me #set b to 'me'

it is really easy to miss the double-space when reading this line from a listing on a website say, whereas

set a=look at ## set a to 'look at ' set b=me## set b to 'me'

is much more obvious as there is only one space.

Anyway, I have no really strong opinion for any of the proposals, except I would really like to get some sort of inline comment feature 'officially' into grub4dos, so we can all start commenting the menus which will greatly help people's understanding of the commands :-) Do you see this being possible soon?

Any way, I insist on the symbol " #" (space hash) for leading an inline comment. It is quite close to the Linux way of shell comment.

Other comment symbols would be too complex.

Don't worry about the compatibility issue.

Is that # or # or # or #.

Bearing in mind that unicode fonts may have a two character code after the # if the comment is in say Chinese?

And that menus may have

echo #1 do this first echo #2 do this next echo #3 do this 3rd

and if I wanted such text displayed as the one above - how would I display it because # or \x23 does not work in echo statements - only in titles?

It was actually # with my original idea.

The echo code should do some fixes to deal with backslash thingy.

Perhaps many others of the code need fixing. But bear in mind, we are now just in the stage of "design", not of coding. The goal is to gain a good design.

I still don't know you insist on # when this clearly can break compatibility with existing menu.lst files and causes the user problems if they want to use a # character in a menu - just for the sake of being close to a linux shell comment syntax? Why invent another whole load of new features (like call #0, call #1 call #6, or echo /x23, etc.) just to overcome a problem which you have created by introducing a new rule of using # for comments! Anyone who uses the new grub4dos version which uses # for comments will wonder why the new version does not work with his existing menu properly and simply go back to the old version or complain to you that the new version has a bug because they do not know about the new inline comment feature and maybe ask you to remove it because it is causing problems.

So I still say it is best to use something that will not cause problems to anyone.

e.g.

This will cause very few problems with existing menus. All the user has to do is remember to use this when adding a comment to the line - it will soon be obvious if he does not conform to this rule and existing menus will work as very few will use ## for anything.

I have already coded this into a version and it works well.

P.S. The Python comment construct #! would be good as this would cause very few compatibility issues. Would this appeal to you more?

Yes, I prefer # and I know it would create some problems. If developers/maintainers/users would like to accept my proposal, then they will try their best to avoid those problems. Yes I still insist, the proposal is not bad.

There are many good proposals, including "##" and "#!" you mentioned above. "@" may be another choice.

So which one should be accepted? It seems undeterminable in a short time.